Unidad de prueba de una estructura de datos

Question

Estoy escribiendo una estructura de datos en C# (una cola de prioridad usando un fibonacci heap) y estoy tratando de usarlo como una experiencia de aprendizaje para TDD, que soy bastante nuevo.

Entiendo que cada prueba solo debe probar una parte de la clase para que una falla en una unidad no me confunda con varias fallas de prueba, pero no estoy seguro de cómo hacerlo cuando el estado de los datos la estructura es importante para una prueba.

Por ejemplo,

private PriorityQueue<int> queue; 

[SetUp] 
public void Initialize() 
{ 
    this.queue = new PriorityQueue<int>();  
} 

[Test] 
public void PeekShouldReturnMinimumItem() 
{ 
    this.queue.Enqueue(2); 
    this.queue.Enqueue(1); 

    Assert.That(this.queue.Peek(), Is.EqualTo(1)); 
} 

Esta prueba se rompería si bien Enqueue o Peek se rompió.

Estaba pensando que de alguna manera podría hacer que la prueba configure manualmente el montón de la estructura de datos subyacente, pero no estoy seguro de cómo hacerlo sin exponer la implementación al mundo.

¿Hay una mejor manera de hacerlo? ¿Confiar en otras partes está bien?

EDIT: Tengo una configuración en su lugar, simplemente lo dejé fuera por simplicidad.

Answer 1

Agregue un descriptor de acceso privado para la clase a su proyecto de prueba. Utilice el acceso para configurar las propiedades privadas de la clase de alguna manera conocida en lugar de utilizar los métodos de clases para hacerlo. Como @Steven A. Lowe indicó, también necesita usar los métodos SetUp/TearDown en su clase de prueba para realizar las inicializaciones necesarias entre las pruebas. En realidad, preferiría volver a crear la cola en cada prueba en lugar de reutilizarla entre las pruebas para reducir el acoplamiento entre los casos de prueba.

Answer 2

Creo que esto está bien; pero borre la cola al comienzo de su método de prueba ;-)

Answer 3

Teóricamente, solo desea probar una característica por vez. Sin embargo, si tu cola solo tiene un par de métodos (Enqueue, Peek, Dequeue, Count), entonces estás bastante limitado en el tipo de pruebas que puedes hacer al usar solo un método.

Lo mejor es que no sobreinyecte el problema y simplemente cree unos pocos casos de prueba simples (como el de arriba) y construya sobre eso para asegurar una cobertura apropiada de varias características.

Creo que es apropiado escribir pruebas que cubran características múltiples, siempre y cuando tenga algo debajo que también se romperá si se rompe una de las funciones utilizadas. Por lo tanto, si tiene un banco de pruebas y rompe su Enqueue, obviamente, todas sus pruebas (o la mayoría de ellas fallarán), pero sabrá que Enqueue se rompió debido a sus pruebas más simples. La relación de una prueba con su conjunto de pruebas no debe descuidarse.