Escribe tests. No demasiados. Sobre todo unitarios.
HTML-код
- Опубликовано: 6 сен 2024
- Kent C. plantea cambiar la pirámide por el trofeo de testing, pero… ¿qué es un test unitario? 🤔
├ 👀 Trabaja de Frontend en Codely 👉 bit.ly/codely-f...
└ 🐙 Curso testing en Frontend 👉 pro.codely.tv/...
Tradicionalmente se plantean las capas de test usando la pirámide:
1. En la base tenemos los tests unitarios, que dan menos cobertura pero se ejecutan muy rápido.
2. En segundo lugar, tenemos los tests de integración. tienen más cobertura pero pasan más lentamente.
3. En la parte superior tenemos los tests de aceptación o end to end, que cubren toda la aplicación pero se ejecutan muy lentamente.
Kent C. Dodds plantea cambiar la pirámide por el trofeo de testing, según el cual la mayor parte de nuestro testing se concentra en integración. Pero, ¿qué es un test unitario y qué es un test de integración?
{▶️} CodelyTV
├ 🎥 Suscríbete: ruclips.net/user/c...
├ 🐦 Twitter CodelyTV: / codelytv
├ 🌶 Twitter Núria: / nuria_codes
├ 🧔🏻 Twitter Javi: / javiercane
├ 📸 Instagram: / codelytv
├ ℹ️ LinkedIn: / codelytv
├ 🟦 Facebook: / codelytv
└ 📕 Catálogo cursos: bit.ly/cursos-...
#testing #javascript
¿Y tú qué entiendes por Unit Testing? 🧐
Testear los casos de uso, falseando los datos externos/local para agilizar tiempos de ejecución y confiabilidad, me a encantado el vídeo, cracks ❤️☕
casos de usos ^^
Creo que los unit tests hacen referencia a testear la mínima unidad de código, las funciones.
Para mi el esquema de pirámide de 3 niveles es una simplificación y lo que llaman unit test en este video son en realidad test de componentes.
No estoy seguro si Kent se refiere a tests de componentes o a tests de integración en su tweet, pero coincido con el en que la forma de la pirámide está cambiando, siempre y cuando no le cambiemos el significado a las categorías y dejemos los que antes estaban en la base debajo de la tierra.
Si unitarios son los casos de uso, cómo les llaman a los que no están eligiendo hacer?
Yo? Test Unitarios c:
Gran gran video, este es el tipo de charlas devs que todos queremos y este canal anda al millón en ello!
Ustedes tienen mucha razon al orientarse por tener mas unitarias que integration.
Pero hay arquitecturas que realmente su fuerte esta en los microservicios, aun asi, seguirimos salvaguardando las unitarias en dichos micros, pero las de integracion son importantisimas en esos componentes del backend, alli incluiriamos contract test, component test e integration test. Pero si nos referimos al frontend, ustedes lo dejan muy claro y concuerdo con ello.
Nota: En el backend, tendemos a tener muy pero muy pocas E2E, y crecer en IntegrationTest.
Así es viejo mauro.
Excelente fichaje Nuria 👏
Hola Nuria Javi y Rafa!
La verdad que estoy súper de acuerdo con vosotros, yo la mayoría de los tests que tengo en mis aplicaciones son como los que ha mostrado Nuria y la verdad que son muy cómodos y escalan muy bien.
Lo que sí veo que podría ser mejorable es la forma que habéis usado para mockear el CoursesRepository. Me gustaría saber vuestra opinión en este respecto, pero eso de mockear una clase usando su ruta de importación la verdad es que me chirria muchísimo.
Si no usase TypeScript, lo que haría yo es heredar la clase CoursesRepository para sobreescribir el método "searchAll" y así poder devolver el dato que yo quiera.
Cuando uso TypeScript, lo que recibiría por props el componente CourseCollection sería una interfaz CoursesRepository, para que el componente padre le pase una instancia de CoursesRepositoryHttp y luego para los tests suelo tener una clase CoursesRepositoryFake que simula el comportamiento de la API pero sin atacarla.
También he oido a Carlos Villuendas que se puede simular la interfaz en JavaScript vanilla heredando de una clase cuyos métodos simplemente tienen un throw, para que estemos obligados a heredarla.
Por último, una cosa que también me gusta hacer a mi es inyectar la dependencia no por props, sino por la API de contexto (de Vue o de React, es lo mismo). De esta forma, puedes inyectar la dependencia desde la raíz de la aplicación y los descendientes desconocen la implmentación real de esa dependencia. Básicamente sería usar la API de contexto para tener un contenedor de dependencias.
Por cierto, aunque hayáis concluido que este tipo de tests se llaman "Unitarios" estaría bien poder distinguir estos tests a nivel de "Contenedor" de los tests de los componentes presentacionales.
La verdad que creo que os ha venido súper bien que Nuria haya entrado en el equipo y completar esa patita que os faltaba, espero que estéis todos bien y un saludo gigante!
Ole tú. Muchisísimas gracias por tomarte el tiempo de compartir este pedazo de comentario. Hay puntos muy buenos que sin duda molaría debatir. Por lo pronto quería contestarte al menos para agradece el gesto, contenido, y tono. Así da gusto 😊🙌❤️
@@CodelyTV Jajaja sois unos máquinas! Un saludo desde Tenerife!
@@DanielRamos-zx1kh Saludooooooos
Ui. Tengo algo copiado en el portapapeles y no recuerdo qué era. Lo voy a pegar aquí para que no se me pase y lo sobrescriba con alguna otra cosa 👉😊👼 ruclips.net/video/fEtxdqIcvHw/видео.html
Please, sacad un curso de arquitectura microfrontends con Vue para aplicaciones grandes. Thanks!
me encantaria eso!
Criterio y organización, y siempre tener en cuenta el contexto. Muy buen video
🤯 Ahora todo tiene más sentido!
El tema para mi este es el tema jejejeje cada tipo para su momento y lugar ❤ como siempre un placerako
Gracias Nuria por pregunta lo del repository 🙊🙈
para mi le dieron la vuelta al cambiarle el nombre a los unit test. En mi opinion Los unit test de toda la vida son los tests que prueban la minima unidad de codigo testeable, osea , las funciones.
creo que ustedes se refieren a aumentar los test de componentes y disminuir los tests unitarios; y kent le dice test de integración a los tests de componentes.
creo que los test unitarios van perdiendo fuerza al ser tan propensos a romperse en un refactor y agregar tan poca confianza, y eso indica que la piramide esta cambiando de forma, no es cuestion de cambiarle el nombre a los unitarios xq de ser asi dejamos fuera lo que antes eran unitarios, como si estuvieran bajo tierra, debajo de la pirámide
saludos !
al final la clave es la definición de la unidad :)
Excelente contenido muchachos, se aprende mucho de sus vídeos sigan así
¿Cómo se compaginan éstos tests (y más concretamente los de backend) con TDD?
Es decir, escribir el test primero, puesto que no puedo probar un caso de uso que abarque varios componentes, aunque formen una unidad, si no los he desarrollado primero por partes.
¿No sería más lógico que dichos tests sean (queden al final como) los tests unitarios, y que los tests de integración verifiquen sólo cada lado de la interface de cada nivel mockeando el lado contrario?
👍
Me interesa...🤔
Una explicación brutal. Excelente contenido :D
la VIRGEN SANTA que intro reshulona que habeis montao. Aca mis dies 🔟
Felicidades a ambos!
En el ejemplo, mockeais la llamada a la API. Dudas.
1. ¿Cómo testeas que el backend y su conexión con el front sea correcta si estáis mockeando esa llamada?
2. Definís que se deben testear "casos de uso". Este caso de uso no estaría correctamente testeado porque si no hacéis llamada real a la API, nunca sabréis si el componente en el front mostrará los cursos o no.
Hola! Creo que puedo contestar a tus dudas:
1. El "mockeo" de la api se hace únicamente en los test unitarios, al componente lo único que le interesa es que llamando al método "searchAll" del repositorio obtiene los cursos a pintar. Para testear la comunicación del frontend con la API del backend, bastaría con un test de integración sobre el repositorio que sí que hiciese la llamada al backend, o su defecto, a un fake del mismo.
2. El caso de uso estaría testeado a nivel unitario, ya que el componente mostraría la lista de cursos, independientemente de si estos los obtiene de un API rest en backend o de filesystem. Para una comprobación completa, se podría hacer un test de aceptación (test E2E), que efectivamente llame al backend o donde tenga que obtener los cursos. Normalmente los test E2E son bastante más lentos y se suelen hacer únicamente de "happy paths", mientras que con la forma que comentan de probar los casos de uso, se podría probar rápidamente todas las peculiaridades que tenga el caso de uso.
Espero haberme explicado correctamente 😅
Cool! Gracias por su contenido :)
Como he flipado con este video. Estaba por empezar aprender sobre el testing, y me encontre con esta joyita. Una consulta rapida: 1. ¿En su curso incluyen un certificado? ¿y de que tipo? 2.- ¿Hay devolucion del dinero en caso no sea lo que esperaba? Agradezco de antemano su pronta respuesta. Hasta luego!
Excelente clase! gracias!
Como desarrollador si sabes bien definir límites y unidades de "trabajo" te facilita todo el tema de pruebas, incluiso que herramientas usas
Vamos hombre, Queremos arquitectura exagonal en frontend. Que he visto tres vídeos de codely y ya doy cátedra de las ventajas de la arquitectura exagonal. Tiremos Toda la logica en el frontend y el backend un mero busca y guarda datos, pero con el consuelo que puede hacer estadística con ellos.
Y que pasa cuando hablamos de diseño basado en test? ( TDD ) por lo que entiendo se basa en asegurar la cobertura de testing ( por diferentes tipos de test ) pero como aplica cuando estoy diseñando con TDD?
Videaco. Mis dieses :)
Qué grandes! Gracias :'D
Tienen cursos sobre WSO2 Enterprise Integrator 🤔?
Pregunta, los test los hacen en JS, pues si lo hago en TS, me da error al hacer mockResolvedValue en un metodo, ya que el transpilador no lo reconoce como propiedad del metodo
Tienen algún curso respecto a este tema, sobre testing con vue?
Afirmativo, y hay varios 😊😬
* Curso de Testing Library que justo estamos publicando ahora. Ejemplos con Vue, React, y Angular. Foco justamente en conceptos agnósticos del framework que se use por debajo: pro.codely.tv/library/testing-frontend
* Curso de novedades de Vue 3 aplicadas al Mundo Real™️: pro.codely.tv/library/novedades-vue-3
* Crea una app con VueJS y Jest aplicando TDD. Curso que se ha quedado un poco anticuado en algunas cosas ya que es previo a la publicación de Testing Library, pero que Gualis justo actualizó los ejemplos del repositorio asociado al curso hace poco y te puede servir también: pro.codely.tv/library/crea-una-app-con-vuejs-y-jest-aplicando-tdd
* Testing unidirectional dataflow con Vuex y Jest. En la línea del anterior, pero añadiendo la parte de store centralizado para gestión de estado: pro.codely.tv/library/testing-unidirectional-dataflow-vuex-y-jest
* Migrando a VueJS progresivamente desde 0. Cursaco con un enfoque progresivo para llevar estos conceptos poco a poco a una app ya existente: pro.codely.tv/library/migrando-a-vuejs-progresivamente-desde-0
Saludoooooos
@@CodelyTV Que genial 😃 tienen mucho material sobre este tema, muchas gracias por detallarme toda la información 🙈
Saludos desde El Salvador 👋
Solo una pequeña aportación. Creo que el test te está diciendo que el CurseRepository necesita una interfaz para hacer la abstracción del test unitario del control.
Hola, una consulta, para que me serviría la interfaz (no entiendo bien y tu comentario me ha dado curiosidad)
@@josue10hd Hola, pues digamos que preparas el contrato independiente de la implementación. "Abstracción ".
@@gerarduab9960 oh, ya veo, gracias por responderme, otra consulta, eso me daría un beneficio al momento de hacer los testing?
@@josue10hd No harcodear el test con un mock object. Ya que si cambias la implementación o añades métodos en CourseRepository ya tienes que reescribir test. Digamos que tu test parte de la interfaz en lugar de la implementación. Puesto en la realidad pera este sencillo caso de uso, no sería un problema.
Si son Repository Lovers....
xD
Rafa estubo en la edición del video xD -> "Nos vemos porque tenemos espejos en nuestras casas :P"
Yo no se que manía tienen muchas empresas con el 100% de cobertura... no hay manera de hacerles cambiar de opinion .. pero bue..
me falta aprender los test de integración
Mucha teoría y nada de ejemplos. Saludos!
Hola Nuri, dejate crecer el cabello. Eres muy inteligente y guapa, Cristo te ama!