unit-testing - unitarias - unit testing javascript
Comenzando con la prueba de la unidad (7)
El llamado marco 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.
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:
- La ejecución de las pruebas se vuelve automatizable y repetible
- Puede probar a un nivel mucho más detallado que las pruebas de apuntar y hacer clic a través de una GUI
Mi pregunta es, ¿cuáles son las "mejores prácticas" actuales en términos de herramientas, así como cuándo y dónde usar las pruebas unitarias como parte de su codificación diaria?
Probemos ser un tanto agnósticos del lenguaje y cubramos todas las bases.
Es posible que desee ver TDD en tres tarjetas de índice y tres tarjetas de índice para recordar fácilmente la esencia del desarrollo basado en pruebas :
Tarjeta n. ° 1 Las tres leyes del tío Bob
- No escriba ningún código de producción excepto para pasar una prueba que falla.
- Escriba solo una prueba suficiente para demostrar una falla.
- Escriba solo el código de producción suficiente para pasar la prueba.
Tarjeta n. ° 2: PRIMEROS principios
- Rápido: increíblemente rápido, como en 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 de aprobado y suspenso.
- Oportuno: Producido en bloque con pequeños cambios de código.
Tarjeta n. ° 3: Núcleo de TDD
- Rojo: la prueba falla
- Verde: pases de prueba
- Refactor: código limpio y pruebas
La familia xUnit es el pilar 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 trato de hacer cuando escribo una prueba es minimizar el uso del 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.
NUnit es una buena herramienta para cualquiera de los lenguajes .NET.
Las pruebas unitarias se pueden usar de varias maneras:
- Lógica de prueba
- Aumentar la separación de 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.
- Desarrollo de unidades, algunas personas escriben pruebas antes de escribir el código para probar. Esto te obliga a pensar sobre lo que quieres que haga el código, y luego te da una guía definitiva sobre cuándo lo has logrado.
No te olvides del soporte de refactorización. 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.
Ok, aquí hay algunas buenas prácticas de alguien que no prueba la unidad tanto como debería ... toser.
- Asegúrate de que tus pruebas prueben una cosa y solo una.
- Escriba pruebas unitarias sobre la marcha. Preferiblemente antes de escribir el código contra el que está probando.
- No pruebe la GUI por unidad.
- Separa tus preocupaciones
- Minimice las dependencias de sus pruebas.
- Comportamiento simulado con burlas .
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 testable 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.