unidad de pruebas primitivas

Question

¿Vale la pena escribir unidad de pruebas para el código tan simple:

public class TableController { 
    private TableView view; 

    public TableController(TableView view) { 
    this.view = view; 
    } 

    public void onShowTable() { 
    view.showTable(); 
    } 
} 

Tengo un montón de dicho código muy simple en mis proyectos que conecta controladores, vistas, servicios, servicios remotos , etc. unidad de pruebas sólo tiene que repetir todo y son generalmente más grandes que el propio código:

public class TableControllerTest { 
    @Test 
    public void showTable() { 
    TableView view = createMock(TableView.class); 
    view.showTable(); 

    replayAll(); 

    TableController controller = new TableController(view); 
    controller.onShowTable(); 

    verifyAll(); 
    } 
} 

son tales pruebas realmente se necesita?

Gracias!

Answer 1

No. No tiene que probarlo todo. Por otro lado, es posible que desee intentar invertir el proceso y escribir las pruebas primero, luego el código. En muchos casos, encontrará que si primero escribe la prueba, termina escribiendo un código diferente que pensó que tendría al pensar en ello desde la perspectiva de cuál debería ser el resultado al escribir la prueba en lugar de qué código debería escribir Al escribir pruebas de esta manera, descubrirá que las pruebas tienen mucho más valor que simplemente ejercitar el código con ellas. Una vez que lo domine, también tendrá una idea de cuándo necesita la prueba y cuándo no; por ejemplo, los usuarios de acceso automático a la propiedad no necesitan la prueba de IMO.

Si ya está haciendo las pruebas primero, entonces no estoy seguro de entender la pregunta ya que las pruebas no pueden repetir algo que aún no se ha escrito. Usaste tus pruebas para definir qué deberían hacer los métodos. Esa es una actividad muy útil y también de protección en el caso de que otras pruebas causen un cambio de rotura. Mucho mejor para encontrarlo en una prueba unitaria que en una aplicación en vivo.

Answer 2

Diferentes personas tendrán diferentes opiniones. Definitivamente debe probar todo lo que podría salir mal. Lo que eso significa para ti depende de ti. Las pruebas excesivas pueden ralentizar la productividad al igual que muy pocas pruebas pueden perder problemas. Necesita determinar lo que funciona para usted.

Answer 3

Son necesarios para cuando cambia la implementación de su método y necesita asegurarse de que todavía funciona. Y cuando sucede dos años más tarde, es demasiado tarde para tratar de recordar cómo funcionaba el método para escribir una prueba unitaria: debe hacerlo AHORA.

Son menos necesarios cuando los compara con pruebas en métodos/lógica más complicados, pero necesarios de todos modos.

Answer 4

Las pruebas siempre son buenas, especialmente si espera que su código crezca con el tiempo. Es útil poder verificar si la funcionalidad anterior sigue funcionando bien después de que se refactorice o se realicen cambios importantes en la base de su código.

Sin embargo, en su caso específico, creo que la funcionalidad de estos bits de código es demasiado pequeña para beneficiarse de las pruebas y pruebas que hacen que el ejercicio showTable etc. sea más útil.

Answer 5

No probaría métodos simples de delegación.

No es bonita frase (aunque no puedo recordar quién venía): "Nunca material de prueba que es demasiado simple para romper ..."

código

Answer 6

en mis proyectos que conecta los controladores, vistas , servicios, servicios remotos, etc.

Para ese tipo de cosas, las pruebas unitarias probablemente no sean útiles, pero las pruebas de integración son, es decir,pruebas que verifican la funcionalidad de la aplicación como un todo (probablemente en función del uso) con un mínimo de burla. Estos demoran más tiempo y no se pueden ejecutar en todos los casos extremos, pero son muy valiosos para revelar problemas en la forma en que interactúan los componentes, y en este tipo de código de pegamento.

Answer 7

Las pruebas para módulos como esos no son realmente necesarias. Sin embargo, las pruebas para módulos como ese no son difíciles de escribir. Entonces, realmente no hay daño al escribir las pruebas. También debe recordar que los módulos simples del tipo que ha mostrado tienden a crecer a lo largo del tiempo. Si no tiene una prueba para el módulo, cuando se agrega un nuevo bit de lógica al módulo, puede decidir que el delta entre el módulo anterior y la nueva lógica es demasiado simple para probar. Poco a poco, el módulo crece sin ser probado.

Por lo tanto, al final, escribiré las pruebas incluso para módulos simples, ya que son simples de escribir, y actúan como marcadores de posición para cuando los módulos se vuelven más complicados.