Hola, tengo una consulta, corro el coverage del test runner y me tira 98% utilizando únicamente las pruebas ofrecidas dentro del enunciado.
es necesario que agregue mas? por que comentan que si no hay pruebas personales, no estaría aprobado el TP, es correcto eso?
Otra cosa que me paso es que no encontré alguna situación de necesidad de excepciones en el código, es posible?
Es lo ultimo que me falta.
Gracias.
A mi me pasa exactamente lo mismo (en mi caso me tira 100% con el test runner, y ninguna prueba mía). Con respecto a las excepciones, utilice subclassResponsibility, pero solo eso. El código me quedo tan simple que no logro realizar pruebas que no redunden en las que ya fueron proporcionadas.
Me autorespondo y planteo otra pregunta. Llegué a la conclusión de que debó agregar código si deseo plantear un mejor programa, y eso requerirá de más pruebas, pero si bien responde a buenas prácticas, es un agregado. ¿Está bien?
Llegué a la conclusión de que debó agregar código si deseo plantear un mejor programa, y eso requerirá de más pruebas, pero si bien responde a buenas prácticas, es un agregado. ¿Está bien?
Eso dependerá de qué será aquello que agregues. Pero en términos genéricos sí y es justamente lo que la consigna pide que detallen en la sección de supuestos del informe. Los supuestos no deben agregar muchos requerimientos nuevos, sino solo aquellos que no quedan explícitos en las pruebas de integración y que surgieron a lo largo del proceso de TDD. Por cada supuesto se espera como mínimo dos pruebas unitarias: una que verifique que el modelo funciona como el supuesto dice y otra que prueba que no hace lo contrario (idealmente deben agregarse más casos borde).
En general se esperan muchísimas pruebas unitarias, dado que por cada método de cada clase (que no sea un getter o un setter) debería haber más de dos pruebas unitarias idealmente.
Saludos,
Tomás
Hola Nicolás:
es necesario que agregue mas? por que comentan que si no hay pruebas personales, no estaría aprobado el TP, es correcto eso?
Es correcto eso. Como se indica en la consigna, la entrega debe constar de la implementación de la solución, el informe y del conjunto de pruebas unitarias que fueron realizadas mediante la técnica TDD. Esas tres cosas son necesarias para poder aprobar el TP.
Tené en cuenta que la cobertura de las pruebas es simplemente un indicador de una condición necesaria pero no suficiente para considerar buenas a las pruebas. Se espera que escriban muchas pruebas más que las que están en el enunciado contemplando todos los casos borde posibles y para cada uno de los supuestos, siguiendo las recomendaciones de estas lecturas obligatorias:
- "Unit Testing Guidelines", Petroware SA
- "8 Principles of Better Unit Testing", Dror Helper
- "Pruebas de software", Carlos Fontela
Las pruebas del enunciado son solamente sobre la clase Herrero, por lo que, si en tu modelo creaste más clases (espero que sí) entonces vas a necesitar pruebas unitarias para cada método de cada una de las clases que modelaste (salvo los getters y setters). Es probable que muchas pruebas se parezcan entre sí, pero serán válidas si están probando comportamientos de distintas clases. Además las pruebas del enunciado no son unitarias sino de integración (tienen más de un assert en cada prueba), por lo que esas pruebas solas no cumplen con lo que se espera que entreguen como pruebas unitarias.
Otra cosa que me paso es que no encontré alguna situación de necesidad de excepciones en el código, es posible?
Es posible. Si no agregás ningún supuesto más entonces es posible que exista un modelo que satisfaga el enunciado y no necesite excepciones. En ese caso deberías justificar tu decisión en el enunciado. De todas formas, si agregás algún supuesto que complete los requerimientos del enunciado es muy probable que se te ocurra al menos alguna situación que requiera el lanzamiento de una excepción. En cualquier caso serán pocas y es preferible que hagas pocas excepciones a que agregues excepciones donde no corresponden con el simple hecho de cumplir con la consigna.
Saludos,
Tomás
Ok, si es correcto, contengo mas clases que únicamente herrero.
Un ejemplo seria el Pico, en ese caso debería probar si o si el comportamiento del pico sin importar que se realice en el test de integración, por ejemplo que su perdida de durabilidad inicialmente sea con mayor resistencia y así?
Un ejemplo seria el Pico, en ese caso debería probar si o si el comportamiento del pico sin importar que se realice en el test de integración, por ejemplo que su perdida de durabilidad inicialmente sea con mayor resistencia y así?Sí, exactamente. De hecho, si hicieras TDD de manera muy estricta, la prueba unitaria debió haber sido creada incluso antes de que crearas la clase Pico, dado que son las pruebas que vas creando las que van especificando el comportamiento que tendrán tus implementaciones. Es por eso que las pruebas sirven además como documentación de las invariantes (en lugar de los comentarios que solían poner en Algoirtmos y Programación 2).
ahhhhh perfecto.
Entones no se que tan bien hice TDD por que ya tenia esa clase que nació en base el test de crear pico. y luego los mensajes que necesito pico para luego hacer el refactor correspondiente.
Muchas Gracias!
Saludos.
Hola, tengo una duda respecto a lo que se considera como prueba unitaria. Por ejemplo, cuando el herrero usa el pico puse assert cada vez que lo usa hasta que la durabilidad llega a cero. Había hecho eso antes de crear el método para asegurarme que en cada uso esté correcta la durabilidad. Pero ahora que ya están todas las pruebas no se si es necesario tantos assert. Mi duda es si solo debería poner un assert al final y si al poner más de un assert en una prueba significa que no es unitaria.
Si la prueba tiene más de un assert entonces por definición ya no es unitaria, dado que verifica varias cosas. Esto no quiere decir que esté mal, sino simplemente que no es unitaria. Lo ideal es que haya tanto pruebas unitarias como de integración.
Tené en cuenta que una prueba unitaria tiene que tener un nombre muy específico y estar dividida en tres secciones: arrange, act y assert. En la primera sección te encargas de instanciar los objetos necesarios y de llevarlos al estado adecuado antes de realizar la acción que realizará algún cambio de estado que es el que se verificará al final.
Te recomiendo revisar las pruebas del ejemplo de la Máquina expendedora de bebidas.