¿Qué debe y no debe cubrirse con pruebas unitarias?

Question

Claramente, I don't understand unit testing. Esto está bien, considerando que nunca lo había hecho antes. Estoy comenzando un nuevo proyecto, y quería probarlo desde el principio, así que estoy buscando aprender.

Siempre he comparado las pruebas unitarias con la cobertura del código, pensando que debe tener pruebas unitarias que cubran cada función/método en su aplicación, pero claramente este no es el caso y he entendido mal el concepto.

Así,

• ¿Qué tipo de funciones se benefician de las pruebas unitarias?
• ¿Qué tipo de funciones no se deben probar unitarias?

Answer 1

Según TDD (Test Driven Development) metodología cual examine toda función pública, y cada ruta de ejecución en esa función.

Answer 2

La prueba de unidades es una herramienta, y hay muchos enfoques sobre cómo usarla. Aquí está mi enfoque:

Escribo mis pruebas unitarias contra las firmas de servicio y DAO, y no tanto contra las DTO y los tipos de entidad. La mayoría de los tipos de valores serán probados indirectamente. Sin embargo, se deben probar los métodos equals y hashCode en DTOs y tipos de entidades.

Utilizo pruebas de unidades puras con dependencias falsas y pruebas de integración con el servidor completo. Para una cobertura adecuada, uno necesita ambos.

Answer 3

no tengo una respuesta completa (me gustaría escuchar a alguien que lo hace, la verdad), pero al menos puedo echar un vistazo a algunos puntos ...

1. ya se encuentra en el pista correcta al impulsar el desarrollo de las pruebas en primer lugar. Las pruebas de unidad de ajuste retroactivo en aplicaciones existentes son difíciles y rara vez proporcionan un beneficio real (en cambio, a menudo dan una falsa sensación de cobertura de código). El TDD apropiado es siempre una previsión, nunca una idea de último momento.
2. No me molestaría en probar funciones privadas. Varias herramientas de cobertura de código pueden decir que no se ha probado, pero si es privada, entonces su funcionalidad debe probarse probando los métodos públicos. Los métodos privados son internos y no forman parte de la API, nada fuera de la clase (incluso las pruebas) debe saber o preocuparse por ellos, ya que pueden cambiar fácilmente si se cambia la implementación de esa clase.
3. Enfóquese en la API expuesta de su código. Escriba pruebas contra sus interfaces, no contra sus clases. Las clases mismas se implementan y prueban luego contra las pruebas.
4. Finalmente, y muy importante, estudie lo que está haciendo y cuáles son sus beneficios. Las pruebas de unidad de escritura no son un proceso de marrón y servir. Uno no logra una buena cobertura de prueba simplemente escribiendo pruebas, sino entendiendo TDD y cómo implementarlo. Tomará práctica. Una sugerencia que le daría es hacer un proyecto apropiado de TDD y también tratar de adaptar las pruebas en un proyecto existente. Podemos decirnos el uno al otro todo el día que el primero es mejor que el segundo, pero al hacer ambos puedes distinguir las diferencias y obtener una mejor comprensión de por qué es mejor. Esto lo llevará más allá de solo escribir las pruebas y ser más un experto en TDD y lo que realmente trae a la mesa. Cualquiera puede escribir pruebas, pero con demasiada frecuencia solo están perdiendo el tiempo a menos que realmente entiendan lo que está pasando.