¿Cómo utilizar las pruebas unitarias como fuente de información?

Un colega mío estuvo una vez en un seminario sobre desarrollo ágil, donde escuchó que es posible usar pruebas unitarias como documentación técnica. Algo así como usar pruebas unitarias como un ejemplo de cómo usar la clase.

Una búsqueda rápida en Google proporcionó TDD y documentación , lo que demuestra que debería ser posible. Pero mirando nuestro código, veo que obviamente no pudimos implementar pruebas unitarias de esa manera.

En mi opinión, las pruebas unitarias están ahí para probar el código como una unidad mínima, incluso con la ayuda de clases y funciones simuladas y falsas.

Entonces, las preguntas son:

• ¿No es tarea de las pruebas funcionales mostrar cómo se debe usar una clase (o conjunto de clases)?
• Si es posible utilizar pruebas unitarias como documentación técnica, ¿hay algunas pautas sobre cómo implementar dichas pruebas unitarias?

Si está aplicando TDD, entonces cada prueba unitaria que escribió corresponde a una funcionalidad de una clase. Entonces, a medida que escribe pruebas, en realidad está creando las funcionalidades de clase, las dependencias, las excepciones y también la documentación de la clase.

Si no está aplicando TDD, las pruebas unitarias le darán una idea sobre la clase y lo que hace. Los nombres de las pruebas unitarias son muy descriptivos, por lo que no necesita crear una documentación principalmente.

Considere una prueba unitaria como

public void Customer_Service_Can_Register_New_Customers(){...}
public void Customer_Service_Cannot_Register_Customers_With_Duplicate_Emails(){...}

Estos son métodos descriptivos y fáciles de leer también. Entonces también sirven como documentación.

Las pruebas unitarias, si están bien escritas, sirven como documentación de una clase o método o lo que sea.

Las bien escritas conducen a una mayor comprensión al ser fácil de entender lo que están probando, pero incluso las pruebas deficientes le dan al lector una idea de cómo se supone que debe actuar la cosa que se está probando y qué cosas el autor pensó que era importante probar.

Heck, se me conoce por escribir pruebas unitarias para bibliotecas externas, no porque necesiten pruebas, sino porque quiero asegurarme de que mi comprensión de la biblioteca es correcta. Y en el futuro, si alguien tiene preguntas sobre cómo estoy usando las cosas, bueno, eso entiendo, justo en el código de prueba.

Si bien las pruebas funcionales pueden ayudarlo a comprender toda una funcionalidad, una prueba unitaria puede ayudarlo a comprender un pequeño alcance de código (como un solo método).

Las buenas pruebas unitarias también servirán como buena documentación técnica, y hay algunas cosas que pueden ayudar a escribir pruebas buenas, simples y útiles. Los dos puntos más importantes que he encontrado son

• Asegúrese de que todas sus pruebas sean independientes. Debería poder ejecutar cualquier subconjunto de pruebas, en cualquier orden.

• Asegúrese de probar solo una cosa en cada prueba. Esto mantiene sus pruebas específicas, simples, pero no frágiles.

La idea de las pruebas como criterios de aceptación / documentación es excelente. Sin embargo, las pruebas unitarias tienden a centrarse en el diseño de arquitectura / código en lugar de historias de usuarios; tratar de documentar casos o requisitos de uso de nivel superior puede ser incómodo. No lo he investigado mucho (todavía), pero el desarrollo impulsado por el comportamiento podría ayudar con ese problema.

Encuentro ejemplos mucho más fáciles de aprender que la documentación y las pruebas unitarias sirven como tal. No solo eso, sino que me muestran, por ejemplo, qué NO hacer con una unidad.

Sin embargo, no pueden ser la única forma de documentación. Uno debe darse cuenta de que todos los cerebros funcionan de manera diferente. Esa es una cosa que creo que las personas que recomiendan usar JUST pruebas unitarias como su documentación o SOLO el código se pierden por completo. Aún más conmovedor es el hecho de que incluso los cerebros individuales aprenden cosas diferentes de diferentes medios. Aprendo algo completamente diferente de un diagrama de clase de lo que hago solo mirando el código o leyendo documentos de API.

Pero al final del día, si los diagramas y los documentos API son todo lo que tienes, entonces probablemente estoy jodido. Necesito ejemplos Necesito ver que algo se use. Podría buscar el código para esto, y sin ningún otro ejemplo con el que estoy atrapado, pero esto nunca me dirá tanto como una buena prueba de unidad.

Las pruebas de hoy son todo un desastre de terminología donde diferentes personas significan cosas ligeramente diferentes y las definiciones han cambiado con el tiempo.

Por ejemplo, TDD solía ser algo que ahora se llama BDD. La distinción se debe a que lo que era la prueba unitaria a través del desarrollo basado en pruebas es ahora un enfoque mucho más detallado para los métodos de prueba (generalmente generados por herramientas automatizadas). Lo que solía ser TDD era una forma un poco más gruesa de probar unidades del tamaño de clases, lo que creo que ahora se llama prueba funcional.

La idea de que puede usar (alguna forma de) prueba es que puede escribir una prueba que se parezca a cómo el usuario usaría una unidad de su código. Se convierte en un ejemplo para los documentos y una prueba al mismo tiempo.

Entonces, si tuviera una clase de red simple (por ejemplo). En lugar de probar cada método individualmente, se acercaría a la prueba de que la clase es la unidad que necesita prueba. Luego, su prueba de unidad ejercitaría toda la unidad llamando al método para inicializar el objeto, configurando el host y el puerto, y llamando a un método para enviar datos, posiblemente llamando a un método para recibir también.

Todo eso puede caber en una única 'prueba unitaria' que probaría el objeto configurándolo en un estado configurado y haciendo que funcione. Otras pruebas unitarias lo ejercitarían con datos incorrectos, pero no es necesario incluirlos en la documentación.

Hoy en día, esto no se considera prueba de unidad, pero todo se reduce a su definición de unidad.