Haciendo Pruebas Automatizadas en Laravel [PARTE I]

Haciendo Pruebas Automatizadas en Laravel

Deja una respuesta

Comment as a guest.

  1. Muy buen contenido, a por el segundo!

    pueden recomendar alguna otra fuente donde continuar, en google hay bastante, pero a veces se saltan mucha teoría o no son didácticos.

    Gracias!

  2. Saludos Matias, excelente p√°gina y muy buen art√≠culo, de verdad que encontrar esta web ha sido de bastante ayuda. Solo una peque√Īa sugerencia y espero que me la permitas, encontre primero la parte 2 de esta guia, y aunque no fue dificil, pues si tarde algo en encontrar esta primera parte, se que es una tonteria pero sugiero linkear esta parte en la otra, te ayuda con SEO y facilita al lector encontrar el principio de tan buena documentaci√≥n. Gracias nuevamente por tu trabajo, seguire navegando y disfrutando del contenido, saludos.

      1. Gracias Matia, estoy usando laravel 7 y tengo problemas con las aserciones de bases de datos. Cuando hago el post(route(‘register’) …no me genera la nueva ruta HOME. El assertRedirect se termina cayendo.

        1. Verifica que la ruta Route::get('/') tenga ->name('home'). O cambia el assert a assertRedirect(url('/')) o solo con la barra /.

  3. ojo que en laravel 8 por lo menos, la funcion register_creates_and_authenticates_a_user sin faker, falla xq la password debe tener 8 caracteres minimo! saludos! gran articulo! ūüėÄ

  4. Buenos días, se que existen pruebas unitarias, de integración y funcionales, dentro de laravel las pruebas funcionales son las mismas que de integración? veo que laravel por defecto solo trae dos carpetas para pruebas unit e feature

    1. Como estas Oscar?
      No, las pruebas funcionales no son las mismas que las de integración.
      Las funcionales abarcan las de integración y las unitarias pero su contra es que tardan bastante tiempo si cubrís todos los casos con tests funcionales. Conviene crear una carpeta para las de integración y poner ahí los casos de pruebas de integración.

      1. Muchas gracias por tu tiempo Matías. Es que tengo un gran vació nosotros solemos hacer los test tipo:

        factory(…)->create()

        $this->post(…)

        $this->assertOk()
        $this->assertDatabaseHas(….)

        Pero en una consultoria, nos decían que esas eran pruebas de integración y que no debíamos hacerlas conectando a una base de pruebas sino a mockups, lo cual entiendo para integraciones externas como DHL en las cuales si usamos mockery para los tests pero no vemos sentido en usar mocks para la base de datos ya que ampliaría el margen de error, ya que el mock retornara que la operación fue exitoso sin importar que el código final no funcione.

        Por eso tengo la duda, las pruebas de integración son solo para probar componentes externos como integraciones con otros sistemas en las cuales se usan mocks para simular la respuesta? y las que hacemos actualmente si serían las funcionales? o como una funcional incluye una de integración?

        1. De nada Oscar.
          Es correcto lo que les dijeron en la consultoría. Las pruebas de integración no tienen que ver con la BD sino con la integración entre componentes de software (pueden ser librerías externas, como con otros módulos de tu aplicación).

          Las pruebas de integración tienen más que ver con como escribís tu código.

          Por darte un ejemplo bien b√°sico: imagina que tenes que desarrollar una funcionalidad de ¬ęRegistrar usuario y suscribirlo al newsletter en el mismo momento si el usuario lo desea¬Ľ.
          Por un lado vas a desarrollar el ¬ęcomponente de software¬Ľ para la registraci√≥n de usuario y por otro lado desarrollas el ¬ęcomponente de software¬Ľ para la suscripci√≥n al newsletter. Vas a tener 2 componentes que se ¬ęcomunican¬Ľ entre ellos (ya que la suscripci√≥n no se puede producir si el usuario no se registra).
          Entonces, vas a tener pruebas unitarias para cada componente que validan sus casos particulares. Despu√©s vas a tener pruebas de integraci√≥n que validan como funciona un componente junto con el otro (sin ir a BD, porque te interesa nada m√°s como se comporta la interacci√≥n entre los 2 componentes). Y despu√©s vas a tener 1 o 2 pruebas m√°s que ser√≠a las funcionales, que son las pruebas m√°s parecidas a las que hace el usuario cuando usa la funcionalidad (por eso los test funcionales si son las √ļnicas que van a BD).

          Si escrib√≠s toda esta misma funcionalidad en un √ļnico m√©todo de un controlador, entonces no tendr√≠as test de integraci√≥n para hacer. Como dije, tiene mucho que ver como escrib√≠s tu c√≥digo.

          Te ayude? Cualquier duda, volve a preguntar ūüĎć
          Saludos.

      2. Matias Echazarreta Buenos días Matias.

        Muchisimas gracias por tu tiempo y ayuda, son muy valiosos y me has despejado varias dudas. Me podr√≠as enviar tus datos de contacto, me interesar√≠a saber si dictas capacitaciones ūüôā mi correo es oscar.sanchez@savne.net

Sliding Sidebar

Matias Echazarreta

¬°Hola!

Mi nombre es Matias Echazarreta.
Soy desarrollador web con m√°s de 12 a√Īos de experiencia.¬†Amante de Laravel, de los libros y del rock de los ’90. Te puedes comunicar conmigo¬† por trabajos de contrataci√≥n, haciendo click aqu√≠.

Nuestro Patreon

Desde Patreon puedes solicitar asesoria personalizado. ¬°Ir a Patreon!

Suscríbete a nuestra lista de correo