TDD: Métodos de "solo prueba"

Question

Buscando algunos consejos prácticos aquí y cualquier experiencia que la gente haya tenido en una situación similar.

Usamos una metodología de BDD/TDD para construir nuestro software (aplicación bastante grande/compleja) El resultado final es .. especificaciones de comportamiento (estilo Dado/Cuando/Luego) derivado de los requisitos del negocio, pruebas unitarias que reflejan estos y código que refleja los requisitos de las pruebas. Sin embargo, recientemente nuestro departamento de pruebas ha comenzado a ejecutar pruebas de integración y comprensiblemente quieren usar nuestro código de lógica empresarial (ya aprobado) para configurar y desmontar el estado de prueba (en lugar de tener que tratar directamente con una base de datos) se preocupan principalmente por las pruebas a través de la interfaz de usuario de la aplicación y no quieren gastar todo el día disputando bases de datos.

El problema es que algunos de los repositorios de entidades no tienen métodos de eliminación ya que todavía no se han expresado los requisitos empresariales. Muchos tienen Archive/Reinstate/backup, etc. (y pueden tener pendientes pendientes en el backlog).

Así que ahora tenemos un departamento de pruebas. requisito para la eliminación (pero uno que entra en conflicto con las historias de usuarios de negocios)

Entonces .... Mi pregunta es ... si tuviera que agregar métodos específicamente para el departamento de pruebas ... cuál es la mejor manera de manejar estas. Entiendo que esto generalmente se considera una mala práctica en "Utopía TDD", pero de manera realista, ¿cómo se ha enfrentado a este tipo de conflicto?

Los primeros pensamientos que he tenido son o bien el uso de nombres ...

void TestOnly_Delete(Guid id){} 

... atributos ...

[TestOnly] 
void Delete(Guid id){} 

... o directivas del compilador ...

#if TESTBUILD 
void Delete(Guid id){} 
#endif 

Por lo menos, los desarrolladores pueden saber que no se deben llamar a los métodos TestOnly y, como máximo, los métodos de prueba no se implementan en las compilaciones de producción.

... o simplemente hacer trampa y añadir una historia de usuario para gestionar esa manera ;-)

Cualquier experiencia o consejo agradecido apreciado?

Gracias de antemano.

Answer 1

Su primera preocupación debería ser ¿Agregar esta funcionalidad mejora o deteriora la API actual? Un escenario típico en TDD es que un miembro de la clase (inicialmente) solo es necesario por razones de prueba, pero cumple con todas las pautas de diseño de API normales, por lo que no daña (y a menudo resulta ser una valiosa adición en el código de producción también).

Cuando esto es cierto, entonces por supuesto solo agréguela si puede hacerlo fácilmente.

A veces, sin embargo, ocurre lo contrario. En este caso, debe resistir la tentación de agregar el miembro. Sin embargo, a menudo puede seguir el Open/Closed Principle y abrir su API para que otros puedan agregar la funcionalidad deseada. Testability is really just another word for the Open/Closed Principle.

En su caso, la solución más simple podría ser simplemente asegurarse de que las clases en cuestión no se hayan sellado y luego solicitar al departamento de pruebas que derive de esas clases e implemente la funcionalidad por sí mismo. Si no tienen esta capacidad, puede hacerlo por ellos, manteniendo las subclases solo en prueba.

Answer 2

En mi código, se crea una subclase: por ejemplo, si tengo una clase DataLayer que tiene todos los métodos públicos para acceder a la capa de datos, entonces puede ser una subclase con una subclase Test_DataLayer, que hereda los métodos de DataLayer y que además implementa cualquier método adicional que desee como Delete, y cuya implementación puede acceder a métodos internos o protegidos de la clase base.

Answer 3

Por lo general, termino con un proyecto/biblioteca de "solo prueba" que contiene las clases simuladas/auxiliares que necesito para mis pruebas. Agregar las clases/métodos necesarios en esta biblioteca simulada, que no está incluida en el código de producción, parece una opción natural para este requisito. Si todavía no tiene una biblioteca de este tipo y no desea crear una, marcaría, si fuera posible, los métodos internos y solo los expondría al marco de prueba. No especifica la plataforma, pero sé que esto es posible con C# /. NET y a menudo uso esta capacidad para dar a mis pruebas acceso a métodos que de otro modo no estarían disponibles fuera de la biblioteca.

En otro aspecto, yo diría que los probadores son una parte tan importante de su análisis de requisitos como los clientes reales. Al igual que tenemos algunos requisitos que son puramente para nuestras necesidades de desarrollo, también tenemos algunos requisitos para las pruebas. El truco, como está descubriendo, es desarrollar el código de una manera que todos de las necesidades de los interesados ​​se satisfagan tanto como sea posible. Cuando las necesidades entran en conflicto, tratamos de utilizar el mejor compromiso posible. IMO, que permite eliminar de bibliotecas solo de prueba es un compromiso razonable con la necesidad del cliente de seguridad de los datos (sin eliminar).

Answer 4

Esta es una pregunta interesante. Tengo un pensamiento, pero no estoy seguro de si será una respuesta a su problema.

Crearé personalmente un conjunto explícito de interfaces heredando de lo que ya tienes para la entidad, como IIntTest_Customer: ICustomer, y definiré el método de eliminación allí. Si es posible, intente poner todas estas interfaces en proyectos separados para que el desarrollador ni siquiera tenga referencias del proyecto habitual y evite el uso accidental de ellas. El departamento de pruebas usará estas interfaces de prueba internas específicas para su propósito de prueba.

Para lograrlo, quizás tenga que refactorizar su código actual y cambiar la entidad para implementar estas interfaces de prueba internas, y con la jerarquía de herencia todo su código existente debería seguir funcionando que se refiera a la interfaz base.

Answer 5

Nunca agregaré eliminación u otros métodos de limpieza a mi código solo para admitir las pruebas automatizadas.

Hay tantas alternativas, que van desde la gestión inteligente de transacciones hasta la restauración automática de bases de datos.