Comenzando con Pruebas unitarias

Question

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

• Ejecución de las pruebas se convierte en automatizar-poder y repetible
• Puede probar a un nivel mucho más granular que apuntar y hacer clic con el botón de prueba a través de una interfaz gráfica de usuario

Rytmis

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

Tratemos de ser un tanto agnósticos del idioma y cubrir todas las bases.

Answer 1

Ok, estas son algunas de las mejores prácticas de alguien que no prueba tanto como debería ... toser.

1. Asegúrese de que sus pruebas de ensayo one cosa y sólo una cosa.
2. Escribir pruebas de unidad sobre la marcha. Preferentemente, before escribe el código con el que está probando.
3. No pruebe la GUI por unidad.
4. Separate your concerns.
5. Minimice las dependencias de sus pruebas.
6. Simulacro de comportamiento con mocks.

Answer 2

La familia xUnit es la base de las pruebas unitarias. Están integrados en los gustos de Netbeans, Eclipse y muchos otros IDEs. Ofrecen una solución simple y estructurada para las pruebas unitarias.

Una cosa que siempre intento hacer al escribir una prueba es minimizar el uso de código externo. Con esto quiero decir: trato de minimizar la configuración y el código de desmontaje de 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 3

El marco denominado xUnit es ampliamente utilizado. Originalmente fue desarrollado 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 dices que estás usando pruebas unitarias, la mayoría de los otros desarrolladores supondrán que te refieres a xUnit o similar.

Answer 4

Un gran recurso para "mejores prácticas" es el Google Testing Blog, por ejemplo, una publicación reciente en Writing Testable Code es un recurso fantástico. Específicamente, sus publicaciones semanales de la serie 'Probando en el inodoro' son excelentes para publicar en su cubo o inodoro, por lo que siempre puede estar pensando en realizar pruebas.

Answer 5

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

Las pruebas unitarias se pueden utilizar en un número de maneras:

1. Lógica Prueba
2. Aumentar la separación de las unidades de código. Si no puede probar completamente una función o sección de código, las partes que lo componen son demasiado interdependientes.
3. Desarrollo de la unidad, algunas personas escriben pruebas antes de escriben el código que se probará. Esto lo obliga a pensar en lo que quiere que el código haga, y luego le da una guía definitiva sobre cuándo lo ha logrado.

Answer 6

Es posible que desee ver en TDD on Three Index Cards y Three Index Cards to Easily Remember the Essence of Test-Driven Development:

Tarjeta # 1. Tres leyes del tío Bob

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

Tarjeta # 2: Principios PRIMEROS

• rápido: abrumadoramente rápido, como en cientos o miles por segundo.
• Aislado: la prueba aísla claramente un error.
• Repetible: puedo ejecutarlo repetidamente y pasará o fallará de la misma manera cada vez.
• Autoverificación: La prueba es inequívocamente aprobada y no aprobada.
• Oportuno: producido en bloque con pequeños cambios de código.

Tarjeta # 3: Base de TDD

• Rojo: prueba falla
• verde: prueba pasa
• Refactor: código limpio y pruebas

Answer 7

No se olvide de refactorización apoyo. ReSharper on .NET proporciona refactorización automática y soluciones rápidas para códigos faltantes. Eso significa que si escribe una llamada a algo que no existe, ReSharper le preguntará si desea crear la pieza faltante.