No tienes acceso a esta clase

隆Contin煤a aprendiendo! 脷nete y comienza a potenciar tu carrera

Metodolog铆as

12/27
Recursos

Aportes 8

Preguntas 2

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad?

o inicia sesi贸n.

Resumen

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 鈥淢antra鈥 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.

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.

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.

Metodolog铆as

  1. TDD -> Test Driven Development: Primero escribimos las prubeas y despu茅s el c贸digo de la l贸gica.
  2. BDD -> Behavior Driven Development: De acuerdo a los requisitos, escribimos las pruebas, un poco m谩s reales a lo que pasar铆a en producci贸n.

Hay que tener cuidado con los falsos positivos y los falsos negativos (este se da cuando solamente pruebas el happy path).

En esta parte del curso, me acabo de dar cuenta que en la empresa donde trabajo, aplicamos TDD + BDD

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