Directrices para una mejor unidad de pruebas de

Question

Jimmy Bogard, escribió un artículo: Getting value out of your unit tests, donde da cuatro reglas:

• nombres de prueba debe describir el qué y el por qué, desde la perspectiva del usuario
• Las pruebas son código también, darles un poco de amor
• no se conforme en un patrón de fijación/estilo de organización
• uno de configuración, Ejecutar y Compruebe por prueba

En su opinión, estas directrices están completos? ¿Cuáles son sus pautas para las pruebas unitarias? Por favor, evite las expresiones idiomáticas específicas, trate de mantener las respuestas en el idioma.

Answer 1

Hay una entera, 850 páginas del libro llamado xUnit Test Patterns que tienen que ver con este tema, así que no es algo que puede ser hervida con facilidad hasta unas pocas reglas duras (aunque las reglas que mencionas son buenas).

Un libro más digerible que también cubre este tema es The Art of Unit Testing.

Si se me permite añadir las reglas que encuentro más importante, que serían:

• Desarrollo Guiado por Pruebas uso. Es, de lejos, el camino más efectivo hacia las buenas pruebas unitarias. Tratar de actualizar las pruebas unitarias al código existente tiende a ser difícil en el mejor de los casos.
• Manténgalo simple: idealmente, una prueba de unidad debe tener menos de 10 líneas de código. Si crece a más de 20 líneas de código, debería considerar seriamente refactorizar el código de prueba o la API que está probando.
• Guárdelo rápido. Las suites de pruebas unitarias deben ejecutarse con mucha frecuencia, por lo que debe mantener el conjunto completo por debajo de los 10 s. Eso puede significar fácilmente mantener cada prueba por debajo de 10 ms.

Answer 2

escritura unidad de pruebas es simple, es la escritura de código-unidad comprobable que es difícil.

Answer 3

• Romper el código de prueba de regularidad para ver la eficacia de la unidad de prueba

Answer 4

The Way of Testivus

• Si se escribe código, escribir pruebas.
• No se atasque en el dogma de prueba de la unidad.
• Prueba de unidad de abrazo karma.
• Piense en el código y la prueba como uno.
• La prueba es más importante que la unidad.
• El mejor momento para realizar la prueba es cuando el código es nuevo.
• Las pruebas no se vuelven inútiles.
• Una prueba imperfecta hoy es mejor que una prueba perfecta algún día.
• Una prueba fea es mejor que ninguna prueba.
• A veces, la prueba justifica los medios.
• Solo los tontos no usan herramientas.
• Fallan las buenas pruebas.

Answer 5

Para muchas más ideas buenas para escribir pruebas unitarias, search stackoverflow.com.

Answer 6

Eche un vistazo a la cobertura del código de sus pruebas y trate de hacerlo razonablemente completo (para casos de error, usaría algún criterio para probarlas o no).