Para las clases que tienen varios setters y getters además de otros métodos, ¿es razonable ahorrar tiempo en la escritura de pruebas de unidad para los accessors, teniendo en cuenta que serán llamados mientras se prueba el resto de la interfaz de todos modos?¿La prueba unitaria de los accesorios es una necesidad?
Absolutamente. La idea de las pruebas unitarias es garantizar que los cambios no afecten el comportamiento de forma desconocida. Puede ahorrar algo de tiempo al no escribir una prueba para getFoo(). Si cambia el tipo de Foo para que sea algo un poco más complejo, entonces podría olvidarse fácilmente de probar el acceso. Si está cuestionando si debe escribir una prueba o no, será mejor que la escriba.
En mi humilde opinión, si está pensando en omitir la adición de pruebas para un método, es posible que desee preguntarse si el método es necesario o no. En interés de la divulgación completa, soy uno de aquellos personas que solo agregan un setter o getter cuando se demuestra necesario. Te sorprendería la frecuencia con la que realmente no necesitas acceder a un miembro específico después de la construcción o cuando solo quieres dar acceso al resultado de algún cálculo que realmente depende del miembro. Pero yo divago.
Un buen mantra es siempre agregar pruebas. Si no crees que lo necesitas porque el método es trivial, considera eliminar el método. Me doy cuenta de que el consejo común es que está bien omitir las pruebas de los métodos "triviales", pero debe preguntarse si el método es necesario. Si omite la prueba, está diciendo que el método será siempre sea trivial. Recuerde que las pruebas unitarias también funcionan como documentación del intento y el contrato ofrecido.Por lo tanto, las pruebas de un método trivial establecen que el método está destinado a ser trivial.
Solo las probaría unitariamente si hacen algo más que establecer o devolver una variable. En algún momento, debe confiar en que el compilador generará el programa adecuado para usted.
De acuerdo - una prueba solo es útil si lo que está probando puede ir mal – ChrisF
Pero qué pasa si se modifican más tarde para mantener más lógica. ¿No es el objetivo de las pruebas unitarias detectar los cambios malos en el código? – LegendLength
Me gustaría tener pruebas unitarias para ellos. Si un descriptor de acceso realiza cualquier tipo de trabajo además de simplemente devolver un campo, ese código se probará adecuadamente.
Incluso si un descriptor de acceso determinado no hace otra cosa que devolver un campo, podría modificarse más tarde para hacer algo extra.
Además, es una manera fácil de aumentar el número de pruebas que se ejecutan, lo que a muchos gerentes les gusta.
Si su IDE genera y gestiona modificaciones para los usuarios que acceden --- usted no hará nada especial --- entonces probarlos realmente no es importante; los tipos coincidirán, el nombramiento será por una plantilla, etc.
Mi criterio para la prueba es que se prueban todos los códigos que contienen lógica condicional (while, if, for, etc.). Si los accesadores son simples getters/setters, diría que probarlos es perder el tiempo.
Creo que es razonable ahorrar tiempo y no escribir pruebas de unidad que no creas que serán particularmente útiles.
Si bien la cobertura del 100% de las pruebas es un ideal admirable, en algún momento se encontrará con rendimientos decrecientes en los que el tiempo que pasó escribiendo la prueba no justifica el beneficio que obtiene al obtenerlo.
Siempre puede regresar y agregar más pruebas unitarias más adelante si encuentra situaciones en las que decide que serían útiles.
Creo que la mayoría de la gente dirá que probarlos es una pérdida de tiempo. En el caso del 99% eso es verdad. Si hay un error en un descriptor de acceso y el resto de las pruebas de su unidad no lo detectan de manera indirecta, entonces comenzaría a preguntar por qué esa propiedad está ahí.
Por otra parte, las pruebas de un descriptor de acceso tarda menos de mecanografía que hacer esta pregunta :)
Personalmente les prueba. Pero este es un área gris para mí y no presiono a otras personas de mi grupo para que los prueben, siempre y cuando tengan suficiente cobertura en torno a la funcionalidad de la clase.
lo general, cuando que no hacer pruebas unitarias me hago la siguiente:
Si es así, incluiría una prueba de unidad. Por si acaso, porque si en algún momento en el futuro decides implementar la carga diferida, o algo más avanzado que un simple get/set, entonces necesitarás asegurarte de que esto funcione correctamente.
La mejor práctica para getters es no permitirles arrojar excepciones en absoluto. Setter es otra cosa. Sin embargo, de cualquier forma, si decide que una propiedad posiblemente arroje una excepción, escriba una prueba unitaria para esa propiedad, tanto para un acceso exitoso como para generar la excepción a propósito.
Aparte de eso, no me molestaría, como señaló Dan, "en algún punto, debes confiar en que el compilador generará el programa adecuado para ti".
Nuestra empresa tiene ambos tipos de personas y opiniones. Estoy tendiendo a no ponerlas a prueba en concreto, ya que suelen ser
Hay excepciones sin embargo:
Tanto estos casos Might causa yo para probarlos. El primero más que el segundo.
No-friggin camino! ¡Pérdida de tiempo!
Incluso Bob Martin See SO podcast 41, el abuelo de Agile dice que no.
No tiene que escribir la prueba para las propiedades que no tienen lógica.
La única explicación para probar propiedades simples es aumentar la cobertura de las pruebas, pero es una tontería.
Mi favorito, aunque la comunidad parece estar en desacuerdo – Yarik
Hehehe ... gracias. Normalmente me mantengo al margen de estas discusiones, pero cada vez que veo el "si ... es simple, entonces ..." me hace temblar. –
¿No podría agregar pruebas unitarias especificando el comportamiento no trivial cuando necesita dicho comportamiento? Sin embargo, estoy de acuerdo con solo crear accesores si realmente los necesitas. –