Tests y lógica de negocio

[marcosrmartin]

• [x] ¿Hay un camino claro que permita ir desde el código hasta la historia de usuario que desarrolla, pasando por el mensaje de commit y el issue correspondiente?
• [x] ¿Se ha intentado cubrir con tests una parte de la lógica de negocio que se esté desarrollando?
• [x] ¿Hay un producto mínimamente viable que describa lo que se va a entregar en este objetivo?
• [x] ¿En este producto mínimamente viable se han priorizado unas clases, módulos o paquetes más fundamentales frente a otros, movidos a otro PMV/Hito?
• [x] ¿Se han documentado las elecciones de biblioteca de aserciones y del de test runner?
• [x] ¿Te has asegurado que lo que mencionas como biblioteca de aserciones y test runners lo son realmente y tienen la misma funcionalidad? ¿O estás poniendo unittest como test runner y pytest como biblioteca de aserciones?
• [x] ¿Esa documentación incluye criterios de aceptación y también criterios de búsqueda para las diferentes opciones?
• [ ] ¿Se han seguido los principios F.I.R.S.T. en la creación del test y se ha documentado cómo se ha hecho? No, pero se ha intentado llevar a cabo las prácticas nombradas en https://github.com/goldbergyoni/javascript-testing-best-practices, como el patrón AAA y 3 partes en el nombre del test.
• [x] ¿Se describe claramente en el PMV los tests que hay que pasar para que se considere viable?
• [ ] ¿Se han testeado también las excepciones? No entiendo bien este apartado.

[marcosrmartin]

@JJ Listo para revisión.

[marcosrmartin]

@JJ en cuanto a testear las excepciones, se refiere a que todos los métodos que tengan tests, deberían tener implementada en la clase todas las posibles excepciones?

[JJ]

@JJ en cuanto a testear las excepciones, se refiere a que todos los métodos que tengan tests, deberían tener implementada en la clase todas las posibles excepciones?

Al menos alguna que veas más específica. Las excepciones no son para que se salga el programa; en ese caso no sirven para nada.

[marcosrmartin]

@JJ Listo para revisión.