Pruebas de Integración | MOCKS vs STUBS | Dobles de Prueba 🧩

[@DavidAT98]

El vídeo que mejor explica este tema, 10/10

[@CamiloCubillos-pw2oj]

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.

[@adrianchamorroamat1421]

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.

[@alvarolopez9943]

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.

[@anamariacanosantos2882]

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 💯

[@strangexz]

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

[@ArturoJoseMojicaGuerrero]

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.

[@pinocodex]

Calidad de explicacion! Sencillo y preciso!

[@jhonfredymartinezrealpe9527]

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

[@ManuelZapata]

Excelente Jhon Fredy!! Gracias por el comentario.

[@Roku8500]

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

[@maopuerta3430]

Que gran tema. Seria bueno conocer tu percepcion sobre: Consumer Driven Contract (El TDD de las APIs a nivel arquitectura)

[@ManuelZapata]

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.

[@maopuerta3430]

@@ManuelZapata totalmente de acuerdo manu

[@arceliomontezuma3458]

Muy bien video

[@dargyjuliethlobo5313]

Excelente video, muchas gracias por ayudarme a entender dichos conceptos de manera más rápida, desde hoy soy una seguidora más 🤗🎉

[@krostoncy99]

Muchas gracias Manuel! este contenido me ha servido muchisimo

[@felipemedinasalvatierra2094]

Buen video.

[@guillermoamarilla9601]

Muy Bueno y muy Claro, Muchas Gracias

[@soporteroberto9661]

Esta info vale oro muchas gracias

[@2005bgva]

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.

[@ManuelZapata]

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.

[@kmiiloberrio-dev]

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

[@rennygalindez]

Excelente este video! Gracias

[@nicolasestebancorreabaraho3365]

excelente video, como critica constructiva el circulo del puntero es demasiado denso y no deja ver el código

[@melekapto8499]

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?.

[@fantasma1630]

buen Video

[@exulonk7517]

Gracias, muy buen vídeo.

[@ManuelZapata]

Con gusto!

[@ricardocabra]

Muy buena explicación, gracias

[@ManuelZapata]

Con gusto, Ricardo!

[@YariTaftEs]

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!

[@ManuelZapata]

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.

[@ayalamac]

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?

[@johncerpa3782]

Buen vídeo! Todos tienen algo en común

[@ManuelZapata]

🙌

[@LocalGhost_8080]

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

[@despovizcaino8622]

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

[@luisdavidcastrocoronado4107]

exelente video !!!

[@leandrotorres4440]

Excelente video, podrias por favor ampliar el tema de los spy, me parece que quedó muy corto o faltó un ejemplo mas concreto.

[@cenipe133]

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?

[@erizonencina4917]

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

[@facundovelazco6783]

Crack

[@FranciscoVelasquezE]

Excelente!!!!!!!!!

[@julianpatino8133]

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.

[@kmiiloberrio-dev]

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?

[@adrianvega3148]

Buen video

[@josefuentes4423]

buen video

[@AndresLobaton]

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

[@cricarba]

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.

[@laraveltip3589]

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.

[@AndresLobaton]

@@laraveltip3589 muchas gracias

[@cricarba]

O sea que las pruebas de integración no necesariamente deben ir contra la infraestructira real? Yo puedo hacer dobles de prueba para todo.

[@emersonperalesvillanueva8568]

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)

[@ManuelZapata]

Hola Emerson, qué hace tu API y cómo se puede invocar?

[@DamCipolat]

Esta bueno pero veo bastante de test unitario en esto.

[@sgnshogun]

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 😅