Edgar Mauricio Pérez Rojas
EstudianteRonaldo Delgado
EstudianteAlvaro Eduardo Garzón Pira
EstudianteBrayan Torrealba Sáez
EstudianteMiguel Angel Reyes Moreno
EstudianteSANDRO SIMON
EstudianteNicolas Molina
ProfesorIrving Juárez
EstudianteIván Antonio Bustos Calderón
EstudianteIván Antonio Bustos Calderón
EstudianteNicolas Molina
ProfesorNicolás Sañudo
EstudianteGilbert Ardila
EstudianteArturo Orlando Flores Soto
EstudianteResumen
Metodologías
TDD (Test Driven Development): Desarrollo guiado por pruebas, donde primero se hacen las pruebas antes de escribir el código (primero los expects).
BDD (Behavior Driven Development): Desarrollo guiado por comportamiento de acuerdo a los requisitos y luego las pruebas.
AAA "Mantra" para hacer pruebas
_____ preparar Arrange | Given dado algo _________ ejecutar Act | When cuando resolver hipótesis Assert | Then entonces
concepto Falso Positívo Cuando una prueba indica un error, pero todo está bien, por ejemplo, testeando el método suma de 1 +1 y pongo el expect en 5, es un falso positivo, luego la prueba está mal.
c Falso Negativo Son más comunes, ya que parece que todo está normal, pero no se ha identificado el error, el set de pruebas debería ser más amplio; esto sucede cuando caemos en tan solo, probar el Happy Path, probar las condiciones en las que sabemos que el sistema funciona, por ejemplo, en el SUT de dividir las primeras pruebas salían bien porque no se tomó en cuenta la división entre cero 0, luego se hizo la prueba y el refactor. En caso de falso negativo lo mejor es aplicar TDD.
c Sistema Legacy Son sistemas que te piden agregar pruebas a algo funcional, incluso en paralelo; hay que refactorizar los métodos enormes a pequeños para hacer unit test de pocos a muchos métodos; legacy no lleva una buena arquitectura.
c Clean Architecture Este patrón lleva buenas prácticas desde el principio, cada método está bien dividido y con responsabilidades acertadas, es mucho más facil de agregar el set de pruebas.
muy buen resumen!
Yo no sé ustedes, pero este curso hasta ahora me ha parecido genial, tiene conceptos como el ciclo de vida del software, buenas prácticas, uso de pruebas estáticas con ESLint, metodologías y adicional testing en casi todas sus formas, es un todo en uno, es un muy buen curso hasta ahora desde mi punto de vista.
AAA podría verse como las acciones que ejecutamos al realizar una prueba.
Arrage: condiciones previas.
Act: los pasos a ejecutar.
Assert: verificar lo esperado.
Cuando empleamos BDD, debemos utilizar un lenguaje común (entendido por todo el equipo: técnico y de negocio) llamado Gherkin. Gherkin está compuesto por unas 20 palabras claves, siendo tres de ellas Given, When, Then.
Con esto quería hacer referencia a la semejanza entre estas tres keywords de Gherkin y las AAA.
Metodologías
Hay que tener cuidado con los falsos positivos y los falsos negativos (este se da cuando solamente pruebas el happy path).
Hola. Hace poco vi un video de Youtube en el que se decia que en algunas entrevistas de trabajo (la parte técnica) el candidato no era tomado en cuenta si es que primero no escribia la parte del testing. Desde tu experiencia ¿es esto cierto? ¿Recomiendas incluir el código del testing?
Hola, en algunas entrevistas técnicas de algunas compañías no te piden explícitamente que entregues el código con pruebas, pero esto suma muchos puntos y es un gran diferenciador de los demás candidatos, en otras entrevistas técnicas puede que las pruebas sean algo explícito y por ende esperan que las entregues, lo más normal en este tipo de entrevistas solo entregues la capa de unit tests.
En mi experiencia buscando trabajo, jamás me han pedido hacer pruebas unitarias. Solo me han hecho preguntas acerca de si las conozco y si las he usado, pero creo que no es tan estricto en relación a las pruebas, a no ser que la empresa explícitamente te pida que hagas pruebas
En esta parte del curso, me acabo de dar cuenta que en la empresa donde trabajo, aplicamos TDD + BDD
@Nicolas Molina, en Platzi, utilizan TDD en el desarrollo de los productos?
Hola, en algunos productos si, en otros se usa otros estilos de pruebas, puedes ver que en toda una empresa se usan varios estilos, ya que depende del micro servicio o producto que se esté desarrollando.
jajaja, tuve un falso positivo, testeé expect(multiply(1,1)).toBe(2); y luego me dí cuenta del error expect(multiply(1,2)).toBe(2);;
++Happy path++ como lo menciona el profe se traduce como ++camino de la felicidad++ o ++camino de felicidad++