¿Con qué frecuencia deberíamos escribir pruebas unitarias?

Question

Recientemente, mi mentor en el trabajo me ha presentado el enfoque del desarrollo basado en pruebas, y me anima a escribir una prueba unitaria cuando "tiene sentido". Comprendo algunos de los beneficios de tener un conjunto de pruebas unitarias durante la prueba de regresión y la refracción, pero me pregunto con qué frecuencia y cómo deberíamos escribir pruebas unitarias.

Mi guía de mentor/desarrollador me pide que escriba un nuevo caso de prueba unitario para un flujo de control recién escrito en un método que ya está siendo probado por la clase de prueba existente, y creo que es una exageración. ¿Con qué frecuencia escribes tus pruebas de unidad, y qué tan detallada crees que deberían ser las pruebas de tu unidad? ¡Gracias!

Answer 1

Técnicamente, si está siguiendo un estricto desarrollo impulsado por prueba ... debe escribir sus pruebas de unidad después de haber especificado una parte de su aplicación. Usted debe ir a:

Requisitos del usuario -> Diseño Función -> Pruebas de la unidad -> Código

recuerda, Las pruebas vienen antes de Código de TDD.

Answer 2

Como dijo Justin, debe escribir su prueba unitaria antes de escribir el código.

Si bien esto es probablemente lo mejor que se puede hacer, en algún momento es excesivo. Dependiendo del proyecto, a veces escribo una prueba unitaria solo por cada error que encuentro (y resuelvo).

Claro, probablemente echo de menos algunos de ellos, pero mi unidad de pruebas se vuelve cada vez más eficiente con el tiempo y estoy bastante seguro de que nunca voy a perder un error corregido.

Answer 3

Las pruebas unitarias deben darle confianza, que el código que escribe, hace lo que quiere. Por lo tanto, debe escribir tantas pruebas como sea necesario para darle esta confianza.

Answer 4

pruebas unitarias:

• le dará la confianza para hacer cambios de refactorización a sabiendas de que usted no está rompiendo ninguna otra cosa.
• actúan como una especie de "documentación viviente" de su código, lo que permite a otros saber exactamente cómo se comportará el código en diversas circunstancias.
• al seguir un TDD estricto como se describe en @Justin, pasar todas las pruebas de unidad escritas antes de comenzar a escribir el código le hará saber cuándo está "terminado" la codificación. En mi experiencia, esto también conduce a un código simplificado y más fácil de entender (más limpio).

Como mencione su mentor, solo debe escribir pruebas unitarias que tengan sentido. La regla de oro que uso es que intento escribir pruebas unitarias para piezas de código que ejecutan lógica comercial. Por lo general, no escribo pruebas unitarias para las clases de frijoles con poco más que getters y setters.

Las pruebas unitarias generalmente se vuelven más valiosas con el tiempo a medida que se expanden y mejoran para tratar las correcciones de errores y otras mejoras de código realizadas después de la entrega inicial.

Answer 5

Debe escribir una prueba unitaria siempre que escriba cualquier código. Y, como otros han señalado, en TDD escribe las pruebas antes de escribe el código.

Si cree que es excesivo, pregúntese "si no pruebo este código, ¿cómo sé si funciona?"

Answer 6

Hay una cosa fundamental acerca de las pruebas unitarias cuando se realiza el desarrollo impulsado por prueba, es decir, que la unidad prueba describe la funcionalidad. Si la prueba no define, p. cómo se comportan las entradas nulas, entonces no se puede esperar que funcione.

Answer 7

Escribir pruebas, y lo más importante, el código comprobable es una habilidad independiente, al igual que aprender a programar cada nuevo idioma es una habilidad independiente.

el blog Leer Miško Hevery 's, leer algunos libros (me gustó Test Driven por Lasse Koskela), utilizar algunas herramientas de cobertura de código como Clover, y luego escribir algunas pruebas.

A medida que escribe las pruebas, sus habilidades de prueba mejorarán, y usted comprenderá lo que implica escribir un código comprobable. Luego podrá conocer para su proyecto particular el nivel de cobertura del código que se requiere.

Answer 8

Mi plomo maestro/desarrollo me pide que escriba una nueva prueba de caja de la unidad de control que se ha escrito flujo

¿Cómo surgió que el flujo de control a ser escrito, a menos que se necesitaba para aprobar una prueba de falla? Por el definition of TDD, ningún código de producción llegará a existir, a menos que exista primero una prueba de falla que requiera la escritura de ese trozo de código. Así que debe haber estado escribiendo el código usando alguna técnica de última prueba y no TDD.

Te recomiendo que leas el artículo The Art of Agile Development: Test-Driven Development. Puede practicar TDD usando this tutorial.

Creo que su mentor con la frase "siempre que tenga sentido" puede ser perjudicial, especialmente para las personas nuevas en TDD, porque no es posible tomar una buena decisión al respecto hasta después de muchos años de experiencia, después de uno ha llegado a Ri-level. En una ocasión, al Kent Beck decided to not write a test, Ron Jeffries comentó lo siguiente: "Confío en usted y en otras tres personas para tomar buenas decisiones a corto plazo".

Siempre debe escribir primero una prueba. Todo lo que pueda romperse requiere una prueba. Solo las cosas que nunca podrían romperse, debido a que alguien cambia el código, no necesitan pruebas. Por ejemplo, el código declarativo rara vez se rompe: el código de diseño HTML estático en una página web generalmente no vale la pena probarlo automáticamente (debe probarlo manualmente para ver si se ve bien), pero vale la pena probar cualquier elemento dinámico.

Answer 9

Siempre debe escribir una prueba, si su conjunto de pruebas existente es insuficiente. La mejor señal, que tus pruebas no son suficientes, son errores. Entonces, una buena práctica es escribir una prueba unitaria por cada error que encuentre. Con el desarrollo basado en pruebas, debe comenzar con algunas pruebas, definir la funcionalidad de una clase. Test-Cobertura-Herramientas le da algunas pistas, qué partes podrían necesitar más pruebas.

Answer 10

El derecho/respuesta exhaustiva a esta pregunta debe ser siempre que sea cuestión clave para cada proceso de pruebas, pero voy a responder con simples reglas siguientes (?):

1. Si algún caso de uso es importante escriba la prueba por separado para que alguien más (o usted en el futuro) pueda detectar ese caso al leer o fallar las pruebas.

2. Si se preguntan por más de 5 segundos si algo es importante suficiente para probar o no, entonces supongo que es :-)

3. Si por casualidad las pruebas de este caso es muy difícil/costoso quejan esto a su gerente/líder técnico y omita escribir la prueba.

Answer 11

Personaly Puedo utilizar las pruebas unitarias, cuando tengo datos masivos, y yo no quiero copiar/pegar un montón de System.out.println, y comprobar ellos uno a uno. Con las pruebas de Unidad, pierde 1 hora para escribirlas, y guarda muchas pruebas. Para cosas triviales, prefiero usar la técnica de impresión, o verificar las variables de depuración.

Answer 12

Yo también me he convertido en un converso reciente a TDD y me resulta extremadamente útil. La idea es tal que tan pronto como tenga una especificación, empiece a escribir pruebas unitarias. Una vez que se hayan escrito sus pruebas, una gran mayoría de su código puede provenir de esas pruebas. Lo que queda en tus pruebas es la base de tus afirmaciones y entonces tienes un patrón repetible muy bueno para: escribir prueba, implementar código, confirmar a través de afirmaciones, continuar. ¡Buen material!