Luchando con dependencias cíclicas en pruebas unitarias

Estoy tratando de practicar TDD, usándolo para desarrollar un simple como Bit Vector. Estoy usando Swift, pero esta es una pregunta independiente del lenguaje.

My BitVectores un structque almacena un single UInt64y presenta una API sobre él que le permite tratarlo como una colección. Los detalles no importan mucho, pero es bastante simple. Los 57 bits superiores son bits de almacenamiento, y los 6 bits inferiores son bits de "recuento", que le indica cuántos bits de almacenamiento almacenan realmente un valor contenido.

Hasta ahora, tengo un puñado de capacidades muy simples:

1. Un inicializador que construye vectores de bits vacíos
2. Una countpropiedad de tipoInt
3. Una isEmptypropiedad de tipoBool
4. Un operador de igualdad ( ==). NB: este es un operador de igualdad de valores similar a Object.equals()Java, no un operador de igualdad de referencia como ==en Java.

Me encuentro con un montón de dependencias cíclicas:

1. La prueba unitaria que prueba mi inicializador necesita verificar que el recién construido BitVector. Puede hacerlo de una de 3 maneras:

   1. Comprobar bv.count == 0
   2. Comprobar bv.isEmpty == true
   3. Mira esto bv == knownEmptyBitVector

   El método 1 se basa count, el método 2 se basa isEmpty(que en sí mismo depende count, por lo que no tiene sentido usarlo), el método 3 se basa ==. En cualquier caso, no puedo probar mi inicializador de forma aislada.

2. La prueba para countnecesita operar en algo, que inevitablemente prueba mi (s) inicializador (es)

3. La implementación de se isEmptybasa encount

4. La implementación de se ==basa en count.

Pude resolver en parte este problema introduciendo una API privada que construye a BitVectorpartir de un patrón de bits existente (como a UInt64). Esto me permitió inicializar valores sin probar ningún otro inicializador, de modo que pudiera "arrancar la correa" hacia arriba.

Para que mis pruebas unitarias sean realmente pruebas unitarias, me encuentro haciendo un montón de hacks, lo que complica sustancialmente mi código de prueba y prueba.

¿Cómo se resuelve exactamente este tipo de problemas?

Te preocupas demasiado por los detalles de implementación.

No importa que en su implementación actual , isEmptyse base count(o cualquier otra relación que pueda tener): todo lo que debe preocuparse es la interfaz pública. Por ejemplo, puede tener tres pruebas:

• Que tiene un objeto recién inicializado count == 0.
• Que un objeto recién inicializado tiene isEmpty == true
• Que un objeto recién inicializado es igual al objeto vacío conocido.

Estas son todas las pruebas válidas, y se vuelven especialmente importantes si alguna vez decides refactorizar las partes internas de tu clase para que isEmptytenga una implementación diferente que no dependa count, siempre y cuando tus pruebas sigan aprobadas, sabes que no has retrocedido cualquier cosa.

Cosas similares se aplican a sus otros puntos: recuerde probar la interfaz pública, no su implementación interna. Puede que encuentre TDD útil aquí, ya que luego escribiría las pruebas que necesita isEmptyantes de escribir cualquier implementación para ello.

¿Cómo se resuelve exactamente este tipo de problemas?

Revisas tu pensamiento sobre lo que es una "prueba unitaria".

Un objeto que gestiona datos mutables en la memoria es fundamentalmente una máquina de estados. Por lo tanto, cualquier caso de uso valioso va a, como mínimo, invocar un método para poner información en el objeto e invocar un método para leer una copia de la información del objeto. En los casos de uso interesantes, también va a invocar métodos adicionales que cambien la estructura de datos.

En la práctica, esto a menudo parece

// GIVEN
obj = new Object(...)

// THEN
assert object.read(...)

o

// GIVEN
obj = new Object(...)

// WHEN
object.change(...)

// THEN
assert object.read(...)

La terminología de "prueba unitaria", bueno, tiene una larga historia de no ser muy buena.

Los llamo pruebas unitarias, pero no coinciden muy bien con la definición aceptada de pruebas unitarias: Kent Beck, Test Driven Development by Example

Kent escribió la primera versión de SUnit en 1994 , el puerto a JUnit fue en 1998, el primer borrador del libro TDD fue a principios de 2002. La confusión tuvo mucho tiempo para extenderse.

La idea clave de estas pruebas (más exactamente llamadas "pruebas de programador" o "pruebas de desarrollador") es que las pruebas están aisladas unas de otras. Las pruebas no comparten ninguna estructura de datos mutables, por lo que pueden ejecutarse simultáneamente. No le preocupa que las pruebas se ejecuten en un orden específico para medir correctamente la solución.

El caso de uso principal para estas pruebas es que el programador las ejecuta entre las ediciones de su propio código fuente. Si está realizando el protocolo de refactorización rojo verde, un ROJO inesperado siempre indica una falla en su última edición; revierte ese cambio, verifica que las pruebas son VERDES e intenta nuevamente. No hay muchas ventajas en tratar de invertir en un diseño en el que todos y cada uno de los posibles errores sean detectados por una sola prueba.

Por supuesto, si una fusión introduce una falla, encontrar esa falla ya no es trivial. Hay varios pasos que puede seguir para asegurarse de que las fallas sean fáciles de localizar. Ver

• Parnas: sobre los criterios que se utilizarán en los sistemas de descomposición en módulos
• Rainsberger: las pruebas integradas son una estafa
• Shore: Pruebas sin simulacros: un lenguaje de patrones

En general (incluso si no usa TDD), debe esforzarse por escribir pruebas tanto como sea posible mientras finge que no sabe cómo se implementa.

Si realmente está haciendo TDD, ese ya debería ser el caso. Sus pruebas son una especificación ejecutable del programa.

El aspecto del gráfico de llamada debajo de las pruebas es irrelevante, siempre que las pruebas en sí sean sensatas y estén bien mantenidas.

Creo que su problema es su comprensión de TDD.

Su problema en mi opinión es que está "mezclando" sus personajes TDD. Sus personas de "prueba", "código" y "refactorizador" operan de manera completamente independiente, idealmente. En particular, sus personas de codificación y refactorización no tienen obligaciones con las pruebas que no sean hacer / mantenerlas funcionando en verde.

Claro, en principio, sería mejor si todas las pruebas fueran ortogonales e independientes entre sí. Pero eso no es una preocupación de sus otras dos personas TDD, y definitivamente no es un requisito estricto o incluso necesariamente realista de sus pruebas. Básicamente: no deseche sus sentimientos de sentido común sobre la calidad del código para tratar de cumplir un requisito que nadie le está pidiendo.