Determinando qué unidad de prueba y qué no

Question

Todavía estoy entendiendo el desarrollo impulsado por prueba. Tengo los siguientes requisitos para un módulo de registro de usuario de una aplicación.

1. El sistema debe capturar nombre, apellido, dirección de correo electrónico del usuario y, opcionalmente, dirección postal
2. El nombre y apellido debe ser alfabético
3. El nombre y apellido no puede estar vacía
4. La dirección de correo electrónico debe ser una dirección válida y es obligatorio
5. La dirección postal es opcional.

Para implementar lo anterior en java. He escrito el código siguiente:

1. El grano de java que contiene los campos anteriores y que tiene captadores y definidores correspondientes
2. Validación de anotación para los campos anteriores
3. A DAO para guardar un usuario
4. Una interfaz de usuario para ingresar los detalles del usuario.

Pregunta: ¿Cuál de los códigos anteriores debe cubrirse con pruebas unitarias? Es decir, los get y setters del bean, la presencia de anotaciones de validación, la capacidad del dao de guardar al usuario, la presencia de los elementos relevantes del formulario en la UI.

Answer 1

escribo pruebas para cosas que la razón "puedo He hecho esto mal?". Eso significa que no me molesto en probar las bibliotecas que otros suministraron, solo mis configuraciones de ellas.

Getters y setters - definitivamente no. Yo uso Eclipse para generarlos, no vale la pena probarlos.

Las anotaciones para validación: no probaría que, por ejemplo, implementan correctamente una comprobación nula, confío en que hacen lo que dice en la lata, pero probaría la presencia de ellas. ¿El campo correcto los tiene? Y si los configuré con una expresión regular, probaría que obtuve la expresión regular correcta.

Otro ejemplo, si almaceno mi POJO con Hibernate. No compruebo que Session.save(myObj) está funcionando, pero las cosas que pude haber hecho incorrectamente, como los límites de las transacciones y la configuración de mapeo (se guardan todos los campos) etc.

Las pruebas de interfaz de usuario me parecen realmente difíciles. Muchas veces pensé "esta vez lo haré", pero algo más complejo que una forma, y ​​me rindo. Usar un patrón como MVP significa que puedo inyectar eventos para probar la mayoría de las cosas computacionales, pero aún existe la conexión a la IU que no se prueba.Por lo general, termino con bits de prueba, manejo complejo de datos, cosas que parecen propensas a errores.

Answer 2

Por una cosa que sé sobre TDD, nunca se escribe el código primero.

Primero escribe una prueba, ya que su prueba falla, escribe/genera código para corregirlo y luego escribe más pruebas para romper la funcionalidad que pretende lograr y escribir/corregir el código original para ello.

Lo mejor es que tenga una cobertura de código del 100%.

, consultar Wikipedia para cómo tiene que comenzar con su proyecto con TDD - http://en.wikipedia.org/wiki/Test-driven_development