paint-brush
¿Qué deberíamos estar probando en una aplicación CRUD [laravel]?por@djug
113,465 lecturas
113,465 lecturas

¿Qué deberíamos estar probando en una aplicación CRUD [laravel]?

por Youghourta Benali2018/12/12
Read on Terminal Reader
Read this story w/o Javascript
tldt arrow
ES

Demasiado Largo; Para Leer

Este es un extracto de mi próximo libro electrónico <a href="https://laraveltesting101.com/" target="_blank">Laravel Testing 101</a> . Si aún no ha leído el capítulo anterior (disponible de forma gratuita aquí: <a href="https://youghourta.com/2018/11/27/laravel-testing-101-where-to-start/" target="_blank">Adición de pruebas a su aplicación Laravel CRUD: ¿Por dónde empezar?</a> ), hágalo antes de leer este.

Companies Mentioned

Mention Thumbnail
Mention Thumbnail
featured image - ¿Qué deberíamos estar probando en una aplicación CRUD [laravel]?
Youghourta Benali HackerNoon profile picture

Este es un extracto de mi próximo libro electrónico Laravel Testing 101 . Si aún no ha leído el capítulo anterior (disponible de forma gratuita aquí: Adición de pruebas a su aplicación Laravel CRUD: ¿Por dónde empezar? ), hágalo antes de leer este.

Ahora que comprende que debería analizar las pruebas desde un ángulo diferente y que deberíamos probar principalmente los controladores, puede comenzar a preguntarse: "... pero, ¿qué debo probar exactamente?"

En este capítulo, responderemos esta pregunta y describiremos lo que probaremos en el resto del libro electrónico.

Pero primero, pongamos en funcionamiento la aplicación de demostración sobre la que se basa el libro.

Clonar el siguiente repositorio

[https://github.com/djug/laraveltesting101](https://github.com/djug/laraveltesting101)

y ejecute la aplicación después de seguir todos los pasos en el archivo readme .

Después de iniciar su servidor/aplicación, debería obtener esta página principal:

Hasta ahora, esto es lo que puede hacer dentro de la aplicación:

  • haga clic en "iniciar sesión" o "registrar" para ver las páginas de inicio de sesión y registro.
  • haga clic en "todos los artículos" y accederá a /articles, que contiene todos los artículos generados por el sembrador.

  • haga clic en "escribir un artículo nuevo" ( /new-article ) y será redirigido a la página de registro (dado que para agregar un nuevo artículo es necesario registrarse).
  • desde la página "/artículos", puede hacer clic en el nombre del artículo (ejemplo /articles/15 ) o en los nombres de usuario ( /users/5 ) para ver los artículos o los perfiles de sus autores.

Después de registrarse, podrá ver la ruta /new-article (que redirigía a la página de registro cuando lo intentamos antes sin iniciar sesión)

Después de guardar su artículo, puede verlo y, dado que es su propio artículo, verá el botón "editar artículo" al final de la página (no lo verá en los artículos que no le pertenecen).

Al hacer clic en este botón, obtiene el formulario de edición del artículo, donde puede editar y guardar el artículo o puede eliminarlo.

Al actualizar el artículo, será redirigido a él nuevamente, con un mensaje de éxito.

Pero si lo elimina, será redirigido a la página "todos los artículos" con un mensaje de éxito diferente.

No verá un botón de "editar" si visita artículos que no creó usted mismo, pero si intenta acceder a la página de edición de un artículo que no es de su propiedad a través de la URL directamente (por ejemplo, articles/16/edit ), obtendrá una página 403.

Volvamos a la página "Escribir un nuevo artículo" e intentemos agregar un nuevo artículo con un título corto y/o un cuerpo corto (menos de 10 caracteres).

Recibirás un mensaje de error. Y lo mismo sucede al editar.

Entonces, aunque la aplicación es pequeña, hay varias cosas que debemos probar para asegurarnos de que la aplicación funcione como se esperaba.

Y aquí está la lista:

  1. Un invitado puede visitar y obtener la página de registro
  2. Un invitado puede visitar y obtener la página de inicio de sesión
  3. Un invitado puede ver todos los artículos cuando visita /articles
  4. Un invitado podría ver un perfil de usuario
  5. Un invitado no podía escribir un nuevo artículo y ser redirigido a la página de registro.
  6. Un usuario (es decir, un usuario registrado) podría escribir un artículo
  7. Un usuario podría acceder a la página de edición de sus propios artículos.
  8. Un usuario podría guardar los cambios de sus propios artículos y ser redirigido a la página del artículo después de editar con un mensaje de éxito.
  9. Un usuario podría eliminar sus propios artículos y ser redirigido a la página de todos los artículos con un mensaje de éxito.
  10. Un usuario no debería ver el botón de edición en el artículo que no le pertenece.
  11. Un usuario no podía editar artículos que no le pertenecen.
  12. Un usuario no podía eliminar artículos que no le pertenecen.
  13. Al crear un artículo, el artículo no puede tener un título o cuerpo corto
  14. Al actualizar un artículo, el artículo no puede tener un título o cuerpo corto

Entonces, si logramos automatizar las pruebas de la lista anterior, podemos estar seguros de que cada vez que agregamos una nueva función o cambiamos un código, la aplicación seguirá funcionando como se espera.

En el próximo capítulo, comenzaremos a escribir pruebas con funcionalidades relacionadas con los usuarios invitados.

Si desea seguirlo y recibir notificaciones de cualquier progreso con este libro electrónico (nuevos capítulos gratuitos, por ejemplo), regístrese aquí: https://laraveltesting101.com/