Eliminación de registros en base de datos con Laravel

Automatizar la eliminación de registros es una pieza fundamental en cualquier aplicación web. Siguiendo la metodología TDD (Test Driven Development), primero se escribe la prueba que define el comportamiento esperado y después se construye el código que la hace pasar. Este enfoque garantiza que cada funcionalidad quede verificada antes de llegar al navegador.

¿Cómo se escribe el test de eliminación en Laravel?

El punto de partida es crear una prueba que simule todo el ciclo: crear un registro, eliminarlo y comprobar que ya no existe en la base de datos [0:30].

• Se genera una etiqueta con datos falsos usando el factory: Tag::factory()->create() [1:00].
• Se importa el modelo correspondiente con use App\Models\Tag; [1:15].
• Se envía una petición DELETE a la ruta del recurso, pasando el ID de la etiqueta recién creada [1:40].

Después de la petición, el test verifica dos cosas:

• Que ocurra una redirección al home [2:05].
• Que el registro ya no exista en la tabla de etiquetas, usando assertDatabaseMissing con el nombre de la etiqueta creada [2:15].

php test('se elimina correctamente una etiqueta', function () { $tag = Tag::factory()->create();

$this->delete("tags/{$tag->id}")
    ->assertRedirect('/');

$this->assertDatabaseMissing('tags', [
    'name' => $tag->name,
]);

});

Al ejecutar los tests con el comando test, la prueba falla con un 404 porque la ruta aún no existe [2:50]. Ese error es exactamente lo esperado en TDD: confirma que el test detecta la ausencia de funcionalidad.

¿Cómo se configura la ruta y el controlador para eliminar?

Con la prueba fallando, el siguiente paso es registrar la ruta en el archivo de rutas. Se utiliza el verbo HTTP DELETE en lugar de POST, y se recibe como parámetro el ID del elemento a eliminar [3:10].

php Route::delete('tags/{tag}', [TagController::class, 'destroy']);

Laravel implementa route model binding, lo que significa que al declarar {tag} como parámetro, el framework inyecta automáticamente la instancia del modelo Tag correspondiente a ese ID.

¿Qué hace el método destroy en el controlador?

Dentro de TagController se crea el método destroy [3:30]:

php public function destroy(Tag $tag) { $tag->delete();

return redirect('/');

}

• Recibe por parámetro la etiqueta gracias al route model binding.
• Llama al método delete() de Eloquent para eliminar el registro de la base de datos.
• Redirige al home tras la eliminación exitosa.

¿Qué resultado arrojan los tests después de implementar el código?

Al volver a ejecutar los tests [3:55], las tres pruebas pasan correctamente:

• La verificación del home funciona.
• El guardado de registros funciona.
• La eliminación funciona y la redirección se confirma.

¿Por qué TDD refleja el comportamiento real del navegador?

El ciclo que se ejecuta en el test replica exactamente lo que un usuario haría desde el navegador [4:20]:

• Existe un registro en la base de datos.
• El usuario hace clic en un enlace que apunta a la ruta de eliminación.
• El sistema borra el registro, redirige al home y el elemento deja de aparecer.

La diferencia es que con TDD ese flujo queda automatizado. Cada vez que se ejecutan los tests, se verifica que la eliminación sigue funcionando sin necesidad de abrir el navegador manualmente.

Este patrón —escribir el test, ver que falla, implementar la solución y ver que pasa— se conoce como el ciclo Red-Green-Refactor y es la base de todo desarrollo guiado por pruebas. Si aplicas este mismo enfoque para las operaciones de actualización, tendrás un CRUD completo respaldado por tests. ¿Ya implementaste las pruebas de actualización en tu proyecto? Comparte tu experiencia en los comentarios.