No sabia sobre la existencia de estos temas a nivel de pruebas; me gusta la forma es que explicas y pues vuelves estos temas que no son el fuerte de muchos mas cercanos, entendibles y pues de conocimiento para aportar a las soluciones que uno realice.
Excelente contenido, Manuel. Muuuchas gracias por la explicación; esto da mucho sentido y contexto a este tipo de pruebas, también súper entendido lo de la inyección de dependencias.
más claro imposible, llevo toda 1 semana buscando videos explicando esto y justo subiste esto hace 7 días, de todo lo que he visto este es el mejor, +1 suscriptor.
Vengo del video de pruebas unitarias y me acabo de encontrar este y me cayó de perlas!!! Nuevo suscriptor!!! Muchas gracias por tu excelente contenido. Espero con ansias el video de las pruebas E2E
Buena explicación, aunque creo que las pruebas de integración, para darnos un buen nivel de confianza, deberían validar que se pueden integrar con el componente lo más parecido posible al de producción, es decir, serían pruebas con alto nivel de acoplamiento a las implementaciones. Las de Aceptación abarcarían un espectro más amplio de componentes, desde un punto de vista de usuario. Si ponemos dobles en los test de componentes con la que nos integramos, lo que hacemos en la prueba es validar solo que nuestro componente funciona, pero no podemos garantizar que funcionará en producción con la integración real (nuestras implementaciones de las interfaces). Considero este tipo de pruebas que mencionas en el vídeo como Unitarias (servicios, casos de uso, clases, etc). Por tanto, los dobles de test se añaden cuando no quieres integrarte con la implementación real, e aquí el kit de la questión, estamos evitando integrarnos de verdad y por eso no las considero Pruebas de Integración, sino Unitarias.
Gracias por tu explicación, con ejemplos y concisa, tu canal esta muy bueno para reforzar conocimientos que se olvidan o no se recuerdan con facilidad en verdad gracias :D
Excelente video Manuel. Muchos hacemos pruebas pero desconocemos el transfondo de lo que estamos haciendo. Ahora ya tengo claro si estoy utilizando un Stub o un Mock. Gracias
Tienen mucho potencial los Consumer Driven Contract. Sobre todo cuando hay muchas integraciones con otros sistemas. Creo que requieren una buena madurez en cuanto a testing.
Hola Manuel, mi recomendación es q pongas entre paréntesis la palabra en inglés, por ejemplo para respondedor cuál es el equivalente con el que se le conoce en inglés y asi..... Saludos sigue adelante.
Excelente Manuel, has mejorado mucho en la calidad de la imagen, edición, la forma de explicar y hablar, me super gustó El tema súper útil, usar inyección de dependencias es clave para facilitar el testing. Espero con ansias ejemplos de los próximos conceptos. He usado estos conceptos sin conocer sus nombres. Pero básicamente siempre he usado mocks y fakes. Respecto a los fakes importante aclaración, si bien teóricamente usar un orm nos abstrae del motor sql que estamos utilizando, la realidad es que he tenido muchos conflictos teniendo una db postgres para la app y una sqlite para testing. Hay muchos problemas de incompatibilidad y limitantes como que sqlite no acepta conexiones multiples. Mi consejo, hacer una db igual a la que se va a usar en la app. Utilizando docker y haciendo que el container sea efimero es decir que una vez stoppeado no conserve información y tenga que ser construida la base desde 0 nuevamente. (esto puede no ser tan sencillo por los anonymous volumens pero vale la pena hacerlo. con tempfs en docker compose se puede lograr esto). Mucha suerte!
Gracias por la retroalimentación, Yari! Y gracias también por el consejo. Eso que mencionas es un gran reto de los fakes. Al final del día, estás usando una implementación alterna, que si se comporta diferente a la real, puede que hayan ciertos problemas con la dependencia real que no se estén descubriendo en las pruebas.
Muy bien el video, solo aclarar una cosa que dices, SQLite no es una Base de datos en memoria, como lo puede ser Redis, quizás quisiste decir liviana, lo demás 💯
Excelente Manuel, traigo un debate que sostuve hace un tiempo, cual es tu opinión acerca de la cantidad de pruebas unitarias a realizar, y en el caso de pruebas unitarias de eventos que lógicamente sabemos que nunca van a fallar valen la pena?.
Ví un artículo de Kent C sobre el "trofeo de tests", han escuchado al respecto? como que nos sugieren más pruebas de integración que unitarias y end to end... creo que es muy útil al menos para frontend
Hola Manuel, cómo estás? Genial el video!, Me queda un poco más claro todo el lío de stub y mocks jeje, te quería preguntar, para testear una aplicación hecha con EF, ¿Se crearía una base de datos en memoria o habría otra alternativa?, Gracias
Buen video, Manuel. Una duda aparte, en los ejemplos que muestras usas AAA (Arrange, Act y Assert); y en el ejemplo del libro viene como ???, Exercise y Verify. Qué convención usa el libro?
Manuel, si bien explicas las capacidades que tenemos para hacer test, no logre entender que diferencia hay entre una prueba unitaria y una de integración. Creo que los ejemplos están mas para la explicación de la diferencia de mocks stubs, pero no de que es realmente una prueba de integración, Es decir desde que punto de entrada de mi software lo consideramos integración
Tus videos son buenos, gracias por hacerlo. Ojalá llegues pronto a tus primeros 100K. En este video confunde un poco que te refieras a pruebas unitarias, porque lo que entiendo las pruebas unitarias son totalmente aisladas y es en las pruebas de integración en donde usamos los dobles de pruebas para no depender de componentes externos. Cómo te contacto si me interesa una charla privada para un equipo de desarrollo en una Empresa?
Hola Manuel, excelente video. Una pregunta. Ese tipo de pruebas de integración se pueden hacer en un entorno como Katalon? Cuál está usando ahí en los ejemplos que puso? Gracias.
Manuel que opinas cuando casi todo el código está en el controlador? Refactorizar para hacer pruebas unitarias que se puedan hacer o hacer de una las pruebas de integración de una?(Tomando en cuenta un sistema legacy). Gran Calidad de videos muchas gracias
Refactorizar usando TDD, haces las pruebas del metodo que quieres pasar, luego empiezas a pasar ese codigo del controlador a los servicios y vas ajustando la prueba hasta que la prueba y el metodo hagan lo que se debe.
Hola Andres! No es recomendable tener todo el código en los controladores, se lo considera mala práctica ya que el controlador no esta cumpliendo su función de obtener los datos, delegarlos a las clases correspondientes y generar una respuesta al cliente. Por otro lado para romper esto en sistemas legacy, primero debes tener test end-to-end o de integración que aseguren que no sé rompe nada mientras se refactoriza. A partir de estas pruebas y la refactorización, podrás generar pruebas unitarias que serán las más exhaustivas a nivel lógica de negocio y por eso tendrás tantas (como menciona Manuel en el video). Luego podes eliminar las pruebas e2e y de integración que hayan quedado redundantes con las pruebas unitarias.
Buenas, un api que he desarrollado también caería en la categoría de pruebas de integración o sería una prueba unitaria? Espero su respuesta. Gracias de antemano :D (Y)
personalmente el concepto de "dummy" me sirve para cuando estas leyendo el test saber rapidamente que ese objeto no sirve para nada en el test pero que si es necesario xD
No me queda muy claro el cómo explicas la diferencia de stub y mock, porque si bien cuando explicas el stub nadie me impide que pueda verificar si fue llamado o no un método en particular. Luego la explicación que das sobre el mock a diferencia del stub es que este es un object chismoso, pero conceptualmente el stub también puede serlo si así lo deseo, y viceversa en el mock no estoy obligado a verificar que se llame. Entonces, seguramente el mock es la representación de un objeto sin funcionalidad, y el stub es el comportamiento que le agrego al mock. ¿Que opinas tú, o tienes otro ejemplo más claro que puedas regalarme por favor?
Si, efectivamente a mi también me parecen tests unitarios, no veola diferencia entre los tests unitarios que yo realicé y esta explicación. Pensaba que era yo el único raro... ahora se que no estoy loco jeje 😅
El vídeo que mejor explica este tema, 10/10
Calidad de explicacion! Sencillo y preciso!
No sabia sobre la existencia de estos temas a nivel de pruebas; me gusta la forma es que explicas y pues vuelves estos temas que no son el fuerte de muchos mas cercanos, entendibles y pues de conocimiento para aportar a las soluciones que uno realice.
Excelente contenido, Manuel. Muuuchas gracias por la explicación; esto da mucho sentido y contexto a este tipo de pruebas, también súper entendido lo de la inyección de dependencias.
más claro imposible, llevo toda 1 semana buscando videos explicando esto y justo subiste esto hace 7 días, de todo lo que he visto este es el mejor, +1 suscriptor.
Vengo del video de pruebas unitarias y me acabo de encontrar este y me cayó de perlas!!! Nuevo suscriptor!!! Muchas gracias por tu excelente contenido. Espero con ansias el video de las pruebas E2E
Muchas gracias Manuel! este contenido me ha servido muchisimo
Buena explicación, aunque creo que las pruebas de integración, para darnos un buen nivel de confianza, deberían validar que se pueden integrar con el componente lo más parecido posible al de producción, es decir, serían pruebas con alto nivel de acoplamiento a las implementaciones. Las de Aceptación abarcarían un espectro más amplio de componentes, desde un punto de vista de usuario.
Si ponemos dobles en los test de componentes con la que nos integramos, lo que hacemos en la prueba es validar solo que nuestro componente funciona, pero no podemos garantizar que funcionará en producción con la integración real (nuestras implementaciones de las interfaces).
Considero este tipo de pruebas que mencionas en el vídeo como Unitarias (servicios, casos de uso, clases, etc). Por tanto, los dobles de test se añaden cuando no quieres integrarte con la implementación real, e aquí el kit de la questión, estamos evitando integrarnos de verdad y por eso no las considero Pruebas de Integración, sino Unitarias.
Excelente video, muchas gracias por ayudarme a entender dichos conceptos de manera más rápida, desde hoy soy una seguidora más 🤗🎉
Esta info vale oro muchas gracias
Gracias por tu explicación, con ejemplos y concisa, tu canal esta muy bueno para reforzar conocimientos que se olvidan o no se recuerdan con facilidad en verdad gracias :D
Muy Bueno y muy Claro, Muchas Gracias
Excelente video Manuel. Muchos hacemos pruebas pero desconocemos el transfondo de lo que estamos haciendo. Ahora ya tengo claro si estoy utilizando un Stub o un Mock. Gracias
Excelente Jhon Fredy!! Gracias por el comentario.
Que gran tema. Seria bueno conocer tu percepcion sobre: Consumer Driven Contract (El TDD de las APIs a nivel arquitectura)
Tienen mucho potencial los Consumer Driven Contract. Sobre todo cuando hay muchas integraciones con otros sistemas. Creo que requieren una buena madurez en cuanto a testing.
@@ManuelZapata totalmente de acuerdo manu
Muy bien video
Excelente este video! Gracias
ExcelenteVideo
Muy buena explicación, gracias
Con gusto, Ricardo!
exelente video !!!
Hola Manuel, mi recomendación es q pongas entre paréntesis la palabra en inglés, por ejemplo para respondedor cuál es el equivalente con el que se le conoce en inglés y asi..... Saludos sigue adelante.
Gracias por la sugerencia, Byron. Quizá a la próxima solo dejo los términos en inglés y ya, sobre todo en palabras que no tienen una buena traducción.
Excelente Manuel, has mejorado mucho en la calidad de la imagen, edición, la forma de explicar y hablar, me super gustó
El tema súper útil, usar inyección de dependencias es clave para facilitar el testing. Espero con ansias ejemplos de los próximos conceptos.
He usado estos conceptos sin conocer sus nombres. Pero básicamente siempre he usado mocks y fakes.
Respecto a los fakes importante aclaración, si bien teóricamente usar un orm nos abstrae del motor sql que estamos utilizando, la realidad es que he tenido muchos conflictos teniendo una db postgres para la app y una sqlite para testing. Hay muchos problemas de incompatibilidad y limitantes como que sqlite no acepta conexiones multiples.
Mi consejo, hacer una db igual a la que se va a usar en la app. Utilizando docker y haciendo que el container sea efimero es decir que una vez stoppeado no conserve información y tenga que ser construida la base desde 0 nuevamente. (esto puede no ser tan sencillo por los anonymous volumens pero vale la pena hacerlo. con tempfs en docker compose se puede lograr esto).
Mucha suerte!
Gracias por la retroalimentación, Yari! Y gracias también por el consejo.
Eso que mencionas es un gran reto de los fakes. Al final del día, estás usando una implementación alterna, que si se comporta diferente a la real, puede que hayan ciertos problemas con la dependencia real que no se estén descubriendo en las pruebas.
Buen vídeo! Todos tienen algo en común
🙌
Muy bien el video, solo aclarar una cosa que dices, SQLite no es una Base de datos en memoria, como lo puede ser Redis, quizás quisiste decir liviana, lo demás 💯
Excelente Manuel, traigo un debate que sostuve hace un tiempo, cual es tu opinión acerca de la cantidad de pruebas unitarias a realizar, y en el caso de pruebas unitarias de eventos que lógicamente sabemos que nunca van a fallar valen la pena?.
Ví un artículo de Kent C sobre el "trofeo de tests", han escuchado al respecto? como que nos sugieren más pruebas de integración que unitarias y end to end... creo que es muy útil al menos para frontend
Excelente!!!!!!!!!
Hola Manuel, cómo estás? Genial el video!, Me queda un poco más claro todo el lío de stub y mocks jeje, te quería preguntar, para testear una aplicación hecha con EF, ¿Se crearía una base de datos en memoria o habría otra alternativa?, Gracias
Buen video, Manuel. Una duda aparte, en los ejemplos que muestras usas AAA (Arrange, Act y Assert); y en el ejemplo del libro viene como ???, Exercise y Verify. Qué convención usa el libro?
Buen video
Manuel, si bien explicas las capacidades que tenemos para hacer test, no logre entender que diferencia hay entre una prueba unitaria y una de integración. Creo que los ejemplos están mas para la explicación de la diferencia de mocks stubs, pero no de que es realmente una prueba de integración, Es decir desde que punto de entrada de mi software lo consideramos integración
Tus videos son buenos, gracias por hacerlo. Ojalá llegues pronto a tus primeros 100K. En este video confunde un poco que te refieras a pruebas unitarias, porque lo que entiendo las pruebas unitarias son totalmente aisladas y es en las pruebas de integración en donde usamos los dobles de pruebas para no depender de componentes externos. Cómo te contacto si me interesa una charla privada para un equipo de desarrollo en una Empresa?
buen video
Hola Manuel, excelente video. Una pregunta. Ese tipo de pruebas de integración se pueden hacer en un entorno como Katalon? Cuál está usando ahí en los ejemplos que puso? Gracias.
Excelente video, podrias por favor ampliar el tema de los spy, me parece que quedó muy corto o faltó un ejemplo mas concreto.
Manuel que opinas cuando casi todo el código está en el controlador? Refactorizar para hacer pruebas unitarias que se puedan hacer o hacer de una las pruebas de integración de una?(Tomando en cuenta un sistema legacy). Gran Calidad de videos muchas gracias
Refactorizar usando TDD, haces las pruebas del metodo que quieres pasar, luego empiezas a pasar ese codigo del controlador a los servicios y vas ajustando la prueba hasta que la prueba y el metodo hagan lo que se debe.
Hola Andres!
No es recomendable tener todo el código en los controladores, se lo considera mala práctica ya que el controlador no esta cumpliendo su función de obtener los datos, delegarlos a las clases correspondientes y generar una respuesta al cliente.
Por otro lado para romper esto en sistemas legacy, primero debes tener test end-to-end o de integración que aseguren que no sé rompe nada mientras se refactoriza.
A partir de estas pruebas y la refactorización, podrás generar pruebas unitarias que serán las más exhaustivas a nivel lógica de negocio y por eso tendrás tantas (como menciona Manuel en el video). Luego podes eliminar las pruebas e2e y de integración que hayan quedado redundantes con las pruebas unitarias.
@@laraveltip3589 muchas gracias
excelente video, como critica constructiva el circulo del puntero es demasiado denso y no deja ver el código
Buenas, un api que he desarrollado también caería en la categoría de pruebas de integración o sería una prueba unitaria? Espero su respuesta. Gracias de antemano :D (Y)
Hola Emerson, qué hace tu API y cómo se puede invocar?
O sea que las pruebas de integración no necesariamente deben ir contra la infraestructira real? Yo puedo hacer dobles de prueba para todo.
personalmente el concepto de "dummy" me sirve para cuando estas leyendo el test saber rapidamente que ese objeto no sirve para nada en el test pero que si es necesario xD
Crack
No me queda muy claro el cómo explicas la diferencia de stub y mock, porque si bien cuando explicas el stub nadie me impide que pueda verificar si fue llamado o no un método en particular. Luego la explicación que das sobre el mock a diferencia del stub es que este es un object chismoso, pero conceptualmente el stub también puede serlo si así lo deseo, y viceversa en el mock no estoy obligado a verificar que se llame.
Entonces, seguramente el mock es la representación de un objeto sin funcionalidad, y el stub es el comportamiento que le agrego al mock. ¿Que opinas tú, o tienes otro ejemplo más claro que puedas regalarme por favor?
Esta bueno pero veo bastante de test unitario en esto.
Si, efectivamente a mi también me parecen tests unitarios, no veola diferencia entre los tests unitarios que yo realicé y esta explicación. Pensaba que era yo el único raro... ahora se que no estoy loco jeje 😅
Gracias, muy buen vídeo.
Con gusto!
Buen video.
buen Video