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.
@adrianchamorroamat142126 күн бұрын
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.
@alvarolopez99433 жыл бұрын
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.
@anamariacanosantos28829 ай бұрын
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 💯
@strangexz3 жыл бұрын
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
@ArturoJoseMojicaGuerrero3 жыл бұрын
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!
@jhonfredymartinezrealpe95273 жыл бұрын
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
@ManuelZapata3 жыл бұрын
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
@maopuerta34303 жыл бұрын
Que gran tema. Seria bueno conocer tu percepcion sobre: Consumer Driven Contract (El TDD de las APIs a nivel arquitectura)
@ManuelZapata3 жыл бұрын
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.
@maopuerta34303 жыл бұрын
@@ManuelZapata totalmente de acuerdo manu
@arceliomontezuma34582 жыл бұрын
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
@felipemedinasalvatierra20942 жыл бұрын
Buen video.
@guillermoamarilla9601 Жыл бұрын
Muy Bueno y muy Claro, Muchas Gracias
@soporteroberto96612 жыл бұрын
Esta info vale oro muchas gracias
@2005bgva2 жыл бұрын
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.
@ManuelZapata2 жыл бұрын
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-dev2 жыл бұрын
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
@rennygalindez3 жыл бұрын
Excelente este video! Gracias
@nicolasestebancorreabaraho33658 ай бұрын
excelente video, como critica constructiva el circulo del puntero es demasiado denso y no deja ver el código
@melekapto84993 жыл бұрын
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?.
@fantasma16302 жыл бұрын
buen Video
@exulonk75172 жыл бұрын
Gracias, muy buen vídeo.
@ManuelZapata2 жыл бұрын
Con gusto!
@ricardocabra3 жыл бұрын
Muy buena explicación, gracias
@ManuelZapata3 жыл бұрын
Con gusto, Ricardo!
@YariTaftEs3 жыл бұрын
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!
@ManuelZapata3 жыл бұрын
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.
@ayalamac2 жыл бұрын
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?
@johncerpa37823 жыл бұрын
Buen vídeo! Todos tienen algo en común
@ManuelZapata3 жыл бұрын
🙌
@LocalGhost_80803 жыл бұрын
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
@despovizcaino86223 жыл бұрын
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
@luisdavidcastrocoronado41072 жыл бұрын
exelente video !!!
@leandrotorres44402 жыл бұрын
Excelente video, podrias por favor ampliar el tema de los spy, me parece que quedó muy corto o faltó un ejemplo mas concreto.
@cenipe1333 жыл бұрын
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
@FranciscoVelasquezE3 жыл бұрын
Excelente!!!!!!!!!
@julianpatino81333 жыл бұрын
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-dev2 жыл бұрын
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?
@adrianvega31483 жыл бұрын
Buen video
@josefuentes44233 жыл бұрын
buen video
@AndresLobaton3 жыл бұрын
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
@cricarba3 жыл бұрын
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.
@laraveltip35893 жыл бұрын
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.
@AndresLobaton3 жыл бұрын
@@laraveltip3589 muchas gracias
@cricarba3 жыл бұрын
O sea que las pruebas de integración no necesariamente deben ir contra la infraestructira real? Yo puedo hacer dobles de prueba para todo.
@emersonperalesvillanueva85682 жыл бұрын
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)
@ManuelZapata2 жыл бұрын
Hola Emerson, qué hace tu API y cómo se puede invocar?
@DamCipolat2 жыл бұрын
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 😅