Al convertir mi proyecto de código actual a TDD, he notado algo.

class Foo {
    public event EventHandler Test;

    public void SomeFunction() {
        //snip...
        Test(this, new EventArgs());
    }
}

Hay dos peligros que puedo ver al probar este código y confiar en una herramienta de cobertura de código para determinar si tiene suficientes pruebas.

Usted debe estar probando si elTest evento es despedido. Las herramientas de cobertura de código por sí solas no le dirán si olvida esto.Llegaré al otro en un segundo.

Para este fin, agregué un controlador de eventos a mi función de inicio para que se viera así:

Foo test;
int eventCount;

[Startup] public void Init() {
    test = new Foo();
    // snip...
    eventCount = 0;
    test.Test += MyHandler;
}

void MyHandler(object sender, EventArgs e) { eventCount++; }

Ahora puedo simplemente comprobareventCount para ver cuantas veces fue llamado mi evento, si fue llamado. Con buena pinta. Solo que ahora hemos superado un pequeño e insidioso error que nunca será detectado por ninguna prueba: a saber,SomeFunction() no comprueba si el evento tiene controladores antes de intentar llamarlo. Esto causará una falta de referencia nula, que nunca será detectada por ninguna de nuestras pruebas porque todas tienen un controlador de eventos adjunto de forma predeterminada. Pero una vez más, una herramienta de cobertura de código aún reportará cobertura completa.

Este es solo mi "ejemplo del mundo real" a la mano, pero se me ocurre que muchos más de este tipo de errores pueden pasar, incluso con el 100% de "cobertura" de su código, esto aún no se traduce en el 100% probado. . ¿Debemos tomar la cobertura informada por dicha herramienta con un grano de sal al escribir pruebas? ¿Hay otros tipos de herramientas que atraparían estos agujeros?