¿Deberían probarse unidades de JavaBeans simples que tienen getters y setters simples?¿Deben probarse los objetos de dominio y los JavaBeans simples?
¿Qué hay de los frijoles con un poco de lógica en getters y setters?
No se debe escribir ensayos que:
Lo mismo se aplica a los objetos .NET que solo tienen propiedades (a veces llamados objetos 'Info').
En un mundo ideal, tendrías una cobertura de prueba del 100%, pero en la práctica esto no va a suceder. Por lo tanto, gaste el dinero del cliente donde agregará el mayor beneficio, es decir, escribir pruebas para las clases con estado complejo y comportamiento.
Si su JavaBean se vuelve más interesante, por supuesto, puede agregar un caso de prueba más adelante. Uno de los problemas comunes asociados con Unit Testing/TDD es la creencia errónea de que todo debe ser perfecto la primera vez.
Si no vale la pena probarlo, no vale la pena escribirlo.
Eso no siempre significa que deba escribir pruebas. A veces significa que deberías eliminar el código. ¿Necesitas estos frijoles? ¿Realmente hacen algo importante? Si los necesita, debe escribir pruebas. Si no, elimina el código y vive una vida más feliz sabiendo que tienes menos para mantener.
Solo tiene que probar las cosas que quiere que funcionen correctamente.
(Lo siento a todo el que me robó esa cita de)
Creo que es una de esas preguntas que todo el mundo se pregunta a sí mismo (a sí misma).
Pero considere esto: la lógica interna de los accesorios ahora es muy simple, pero puede cambiar en el futuro y, lo que es mucho más importante, podrá cambiarla a lo que desee si tiene pruebas para los métodos. Entonces, obtienes libertad y confianza por medio de un par de testcases. Suena como un buen negocio, ¿eh?
si es solo un getter/setter sin cambiar nada a los valores, yo diría que no hay necesidad de pruebas. Si hace algo de lógica, algunas pruebas simples de unidad proporcionarán algo de seguridad.
¿Cómo se puede refactorizar de forma segura el código no probado? ¿Qué sucederá cuando cambie su pojo de frijol si no tiene pruebas? ¿Estás creando un Anemic Domain Model?
Debe probar las cosas que tienen algún significado. Getters y setters comúnmente no contienen ninguna lógica y solo se usan en Java por la falta de propiedades. Creo que probarlos es tan estúpido como comprobar que Java devuelve un valor cada vez que evalúas "a.x".
Si el accesorio tiene lógica, depende de usted decidir el umbral. Si tu equipo es lazish es mejor probar toda la lógica. Si es más disciplinado, es mejor encontrar una proporción que no te haga escribir demasiadas pruebas repetitivas.
Como lo dijo Maxim: las pruebas no agregarán funcionalidad adicional a su aplicación, pero le permitirán realizar cambios con más confianza. Para determinar qué clases/métodos chould a prueba la unidad, siempre me pregunto dos preguntas:
Si se responden ambas preguntas con sí, es necesario realizar una prueba unitaria.
En mi opinión, el propósito de escribir pruebas unitarias es probar la lógica comercial de la unidad en prueba. Por lo tanto, si no hay una lógica de negocios (por ejemplo, cuando un getter simplemente devuelve un valor o un setter lo establece) entonces no tiene sentido escribir una prueba. Sin embargo, si hay alguna lógica (getter cambia los datos de alguna manera antes de devolverlos), entonces sí, debe tener una prueba unitaria. Como regla general, creo que no se deben escribir pruebas para beans que no contengan ninguna lógica comercial.
Si tiene una interfaz externa y contiene el código que escribió una persona (en lugar de ser autogenerado por el IDE o el compilador), entonces definitivamente debe probarse.
Si una o ambas de esas condiciones no se cumplen, entonces es una especie de zona gris y se reduce a una cuestión de tipo "cinturón y tirantes" de cuán cuidadoso se siente la necesidad de ser.
Otra regla de oro (similar a lo que otros han dicho) es "probar cualquier cosa que pueda romperse". Para mí, eso excluye getter y setters autogenerados, pero incluye escritos a mano que contienen algo de lógica.