Comenzando con las pruebas unitarias

Question

Las pruebas unitarias consisten, en términos generales, en probar fragmentos de su código de forma aislada con el código de prueba.Las ventajas inmediatas que me vienen a la mente son:

• La ejecución de las pruebas se vuelve automatizable y repetible.
• Puede realizar pruebas a un nivel mucho más granular que las pruebas de apuntar y hacer clic a través de una GUI

Rytmis

Mi pregunta es, ¿cuáles son las "mejores prácticas" actuales en términos de herramientas, así como cuándo y dónde utilizar las pruebas unitarias como parte de su codificación diaria?

Intentemos ser algo independientes del lenguaje y cubrir todas las bases.

Answer 1

Ok, aquí hay algunas de las mejores prácticas de alguien que no realiza tantas pruebas unitarias como debería... tos.

1. Asegúrese de que sus pruebas prueben unocosa y una sola cosa.
2. Escriba pruebas unitarias sobre la marcha.Preferiblemente antes escribes el código con el que estás probando.
3. No realice pruebas unitarias de la GUI.
4. Separa tus preocupaciones.
5. Minimiza las dependencias de tus pruebas.
6. Comportamiento simulado con se burla.

Answer 2

Quizás quieras mirar TDD en tres fichas y Tres fichas para recordar fácilmente la esencia del desarrollo basado en pruebas:

Tarjeta #1.Las tres leyes del tío Bob

• No escriba ningún código de producción excepto para pasar una prueba fallida.
• Escriba solo una prueba suficiente para demostrar una falla.
• Escriba solo el código de producción suficiente para pasar la prueba.

Tarjeta #2:Primeros principios

• Rápido:Increíblemente rápido, como cientos o miles por segundo.
• Aislado:La prueba aísla claramente una falla.
• Repetible:Puedo ejecutarlo repetidamente y pasará o fallará de la misma manera cada vez.
• Autoverificación:La prueba es inequívocamente aprobada-reprobada.
• Oportuno:Producido al mismo tiempo con pequeños cambios de código.

Tarjeta #3:Núcleo de TDD

• Rojo:la prueba falla
• Verde:pases de prueba
• Refactorizar:código limpio y pruebas

Answer 3

La llamada xUnidad El marco es ampliamente utilizado.Fue desarrollado originalmente para Smalltalk como SUnit, evolucionó a JUnit para Java y ahora tiene muchas otras implementaciones como NUnit para .Net.Es casi un estándar de facto: si dice que está utilizando pruebas unitarias, la mayoría de los demás desarrolladores asumirán que se refiere a xUnit o similar.

Answer 4

Un gran recurso para las "mejores prácticas" es el Blog de pruebas de Google, por ejemplo una publicación reciente sobre Escribir código comprobable es un recurso fantástico.Específicamente, sus publicaciones semanales de la serie 'Pruebas en el inodoro' son excelentes para publicar alrededor de su cubo o inodoro, para que siempre pueda estar pensando en realizar pruebas.

Answer 5

La familia xUnit es el pilar de las pruebas unitarias.Están integrados en Netbeans, Eclipse y muchos otros IDE.Ofrecen una solución simple y estructurada para las pruebas unitarias.

Una cosa que siempre intento hacer cuando escribo una prueba es minimizar el uso de código externo.Con eso quiero decir:Intento minimizar el código de configuración y desmontaje para la prueba tanto como sea posible y trato de evitar el uso de otros módulos/bloques de código tanto como sea posible.Un código modular bien escrito no debería requerir demasiado código externo en su configuración y desmontaje.

Answer 6

NUnit es una buena herramienta para cualquiera de los lenguajes .NET.

Las pruebas unitarias se pueden utilizar de varias maneras:

1. Lógica de prueba
2. Incrementar la separación de unidades de código.Si no puede probar completamente una función o sección de código, entonces las partes que la componen son demasiado interdependientes.
3. Impulsa el desarrollo, algunas personas escriben pruebas. antes escriben el código que se va a probar.Esto te obliga a pensar en lo que quieres que haga el código. hacer, y luego le da una pauta definitiva sobre cuándo lo ha logrado.

Answer 7

No olvide el soporte de refactorización.ReSharper en .NET proporciona refactorización automática y soluciones rápidas para el código faltante.Eso significa que si escribe una llamada a algo que no existe, ReSharper le preguntará si desea crear la pieza que falta.