Mi primera vez con Unit Testing (TODO MAL) | la función CodelyTV 29
HTML-код
- Опубликовано: 9 мар 2020
- Nos vamos a remontar a la vez que empezamos a hacer Unit Testing (y tests en general) para ver por qué y cómo empezamos.
Explicando sobretodo todos los errores que cometimos para que así podáis evitarlos y ahorraros muchas horas de vuestra vida. 😅
Y obviamente hablaremos de todas las virtudes que tiene y de por qué lo utilizamos en nuestro día a día (y qué porcentaje de cada tipología usamos).
🔗 Enlaces relacionados
└ ✅ Curso testing: bit.ly/curso-testing
{▶️} CodelyTV
├ 🎥 Suscríbete: ruclips.net/user/CodelyTV?sub_co...
├ 🐦 Twitter CodelyTV: / codelytv
├ 💂♂️ Twitter Rafa: / rafaoe
├ 👨 Twitter Javi: / javiercane
├ 📸 Instagram: / codelytv
├ ℹ️ LinkedIn: / codelytv
├ 𝐟 Facebook: / codelytv
└ 📕 Catálogo cursos: bit.ly/cursos-codely 
Наука
![MAF Teeski - Whole Thing (feat. VonOff1700) [Official Music Video]](http://i.ytimg.com/vi/SHWEj-ndz6g/mqdefault.jpg)
Buen tema habeis tratado hoy! El caso es que los tests son innegociables, pero hay que analizar para que son imprescindibles. En clase empezamos mostrando tests anémicos porque son los más sencillos de realizar cuando estas mostrando sus posibilidades. Pero yo personalmente creo que solo tienen sentido para probar la funcionalidad de los servicios que ofrecemos, yo solo testearia los posibles casos de uso (correctos e incorrectos) de los controladores y el resultado me indicará si sigo cumpliendo requisitos o no. Si aparece un error es tarea del programador depurar donde se ha producido, el test ya ha hecho su trabajo => Reparto de Responsabilidades.
Saludos!!
Directazo y temazo. Mecagontó que no llego a uno. Mis dieses en diferido, como siempre 👏🏻👏🏻👏🏻
¡Hemos llegado a los 200 likes! Así que tocará hablar de la gente de QA 😳
pasame el link, porfa!!
Excelente vista. Se aprende muy rápido con vosotros
Me encanta el contenido, saludos desde Perú.
La risa de Javi, estallándose en directo!
muy buena la función, me gustaría que puedan seguir profundizando sobre estos temas de testing
uff! cuando escuche de testear los métodos privados casi salgo del video, menos mal que esperé al final. 😆
No sé qué hicieron pero el audio se escucha rebien, pónganlo siempre así ☺️
¡Eso haremos! 😊
Muy buenos los consejos
Wow muy buen video, de todas maneras aún no logro distinguir el limite de los test unitarios sin que lleguen a la parte de coverage de los de integración, en su cursos cubren esto más profundamente y con ejemplos??
En cuanto al infrastructure mocking anti-pattern, yo tendria que declarar esplicitamente todas la entidades que utilizo? o podria usa un factoria solo para test ? eso funcionaria?, otra pregunta en que caso esta bien usado el mocking? Gracias, estos temas valen la pena escuchar
Una pregunta, por qué no testear el controlador que si va bien genera el comando que esperamos o si se lanza una excepción se genera la respuesta http esperada. Es decir, mockeando la capa de aplicación y comprobar que el entry point funciona. Dado este punto si testeamos A->B (entrypoint) B->C (application/domain) y C (infrastructura) no nos haría falta el aceptación. Si por el contrario se asume que el test de aceptación cubre suficientemente A para no tener que testearlo aparte, seguramente podamos pensar lo mismo de C, no? :) Y acabar solo los tests unitarios, y aceptación. Me ha surgido la duda.
Con tantos conceptos me pierdo un poco, voy a invertir en los cursos
que pase CI después de 20 intentos, es la felicidad absoluta.
Linea Velocidad: Todos los niveles de la piramide son automatizables, el factor velocidad no deberia aplicar a la ejecucion del test (si son todos automatizables podemos considerar que la velocidad es la misma) sino al tiempo de elaboracion del test, suele ser mas rapido ejecutarlo manualmente que codificarlo para que sea automatizable (aunque se automatiza una sola vez y el manual se realiza n veces, donde para una n suficientemente alta conviene que sea automatizado). Esa linea velocidad solo se mantiene como verdadera, asumiendo todos los niveles automatizables, si suponemos que la codificacion del test supone mas tiempo en un test de aceptacion que de integracion, y mas tiempo en un test de integracion que unitario (que la complejidad de la codificacion aumenta. Algo que podria considerarse "cierto" aunque tb depende de las herramientas con las que contemos).
Niveles piramide: Por otro lado, el peso que debe tener cada nivel seria discutible, la forma no necesariamente debe ser la de una piramide. Eso me parece un constructo teorico mas que practico. Despues de todo, si en los test de aceptacion pruebo todas las posibilidades puedo o no conseguir una cobertura del 100% (idealmente si) y haber realizado implicitamente los test de integracion y ninguno unitario. La division en niveles viene dada, probablemente, por la naturaleza de cada nivel de test. La piramide lo que refleja es que a medida que subimos de nivel deberia haber menos tests que realizar: comparando los extremos, hay mas clases con metodos que casos de uso de la aplicacion.
RUclips feo, sigue sin avisar que esta transmitiendo o que suben video ! Saludos Chicos !
Dale a la campanita, a mi me avisa :D
@@leandrowitzke6405 tengo la campanita desde hace 2 o 3 videos, y nome notifica, y le tengo puedo TODAS LAS NOTIFICACIONES
Por descartar: en el móvil tienes permiso habilitado para las notificaciones de la app de RUclips? O puede que tuvieras el móvil en modo silencioso?
Gracias!!
@@CodelyTV hola chicos, ehm nose, es raro, y en el celular me deberia llegar un correo al gmail, y nome llega nada, antes pero con otros canales si que me llegaba. Nunca he manipulado nada en el movil.
Que tan válido es que un evento sea el que realice un dispatch al bus es decir se habla de eventos de dominio pero en la aplicación donde estoy ahora currando los eventos se encuentran en la capa de aplicación es decir que este dispatch se está produciendo desde la capa de aplicación y no de la de dominio 😢😢😢
Se llegó a hacer el vídeo de la opinión sobre los Q&A? me gustaría saber cuál es para verlo
Se hizo?
Lo del router... Soy culpable, y no hace mucho :S
Hola codelytv, no puedo encontrar el blog de garagenado, me podrías indicar cuales favor :)
Buenas! Aquí el post: garajeando.blogspot.com/2018/03/examples-lists.html
¿Y como llamáis a los tests que solo se hacen test doubles de la parte de infraestructura? Me refiero a que no hay un SUT claro, sino que todas las partes son las "reales" menos las partes de infraestructura. Por ejemplo, tu código utiliza un API de terceros a la que hace peticiones para hacer cosas, pero no puedes hacer un tests que haga llamadas reales cada vez que ejecutas el tests. Pero quieres hacer un tests sobre esa parte haciendo que la llamada a esa API te devuelva un Stub. Pero solo haces un test double de esa parte, el resto funciona tal cual debería funcionar (Una clase llama a otra clase que llama a otra clase que llama a la clase que interactúa con el API de terceros, el Stub devuelve una respuesta enlatada y el flujo sigue normal). He leído a gente que esos los consideran tests unitarios pero que no son isolated. Un saludo