Casos de prueba, "cuándo", "qué" y "por qué"?

Question

Siendo nuevo en el desarrollo basado en pruebas, esta pregunta me ha estado molestando. ¿Cuánto es demasiado? ¿Qué debería probarse, cómo debería probarse y por qué debería probarse? Los ejemplos dados están en C# con NUnit, pero asumo que la pregunta en sí es independiente del idioma.

He aquí dos ejemplos actuales de mi propia, pruebas de un objeto de lista genérica (siendo probado con cadenas, la función de inicialización añade tres elementos {"Foo", "Bar", "Baz"}):

[Test] 
public void CountChanging() 
{ 
    Assert.That(_list.Count, Is.EqualTo(3)); 
    _list.Add("Qux"); 
    Assert.That(_list.Count, Is.EqualTo(4)); 
    _list[7] = "Quuuux"; 
    Assert.That(_list.Count, Is.EqualTo(8)); 
    _list.Remove("Quuuux"); 
    Assert.That(_list.Count, Is.EqualTo(7)); 
} 

[Test] 
public void ContainsItem() 
{ 
    Assert.That(_list.Contains("Qux"), Is.EqualTo(false)); 
    _list.Add("Qux"); 
    Assert.That(_list.Contains("Qux"), Is.EqualTo(true)); 
    _list.Remove("Qux"); 
    Assert.That(_list.Contains("Qux"), Is.EqualTo(false)); 
} 

El código es bastante auto-comentando, por lo No entraré en lo que está pasando, pero ¿este tipo de cosas lo lleva demasiado lejos? Add() y Remove() se prueban por separado, por supuesto, ¿a qué nivel debería acudir con este tipo de pruebas? ¿Debería incluso tener este tipo de pruebas?

Answer 1

Yo diría que lo que realmente está probando son las clases de equivalencia.En mi opinión, no hay diferencia entre agregar una lista que tiene 3 elementos o 7 elementos. Sin embargo, hay una diferencia entre 0 artículos, 1 artículo y> 1 artículos. Probablemente tendría 3 pruebas cada una para los métodos Agregar/Eliminar para estos casos inicialmente.

Una vez que comiencen a aparecer los errores de QA/usuarios, agregaría cada informe de error como un caso de prueba; ver el error reproducir al obtener una barra roja; arregla el error obteniendo una barra verde Cada prueba de "detección de errores" está ahí para quedarse: es mi red de seguridad (léase: prueba de regresión) que incluso si vuelvo a cometer este error, tendré un feedback instantáneo.

Answer 2

¿Es _list una instancia de una clase que usted escribió? Si es así, yo diría que probarlo es razonable. Aunque en ese caso, ¿por qué estás construyendo una clase de lista personalizada?

Si no se trata de un código que escribió, no lo pruebe a menos que sospeche que tiene alguna falla.

---

Intento probar el código que es independiente y modular. Si hay algún tipo de función de Dios en el código que tengo que mantener, elimino todo lo posible en las subfunciones y las pruebo de forma independiente. Entonces la función de Dios puede escribirse para ser "obviamente correcta", sin ramificaciones, sin lógica, simplemente pasando resultados de una subfunción bien probada a otra.

Answer 3

Piense en sus pruebas como una especificación. Si su sistema puede romperse (o tener errores materiales) sin que sus pruebas fallen, entonces no tiene suficiente cobertura de prueba. Si un único punto de falla hace que se rompan muchas pruebas, es probable que tenga demasiado (o que esté demasiado unido).

Esto es realmente difícil de definir de una manera objetiva. Supongo que diría que estoy equivocado por el lado de las pruebas demasiado. Entonces, cuando las pruebas comiencen a molestarlo, esas son las pruebas particulares para refactorizar/reutilizar (porque son demasiado frágiles o prueban lo incorrecto, y sus fallas no son útiles).

Answer 4

Algunos consejos:

1. Cada caso de prueba sólo se debe probar una cosa. Eso significa que la estructura del testcase debe ser "setup", "execute", "assert". En tus ejemplos, mezclas estas fases. Intenta dividir tus métodos de prueba. Eso hace que sea más fácil ver exactamente lo que está probando.

2. Intente darle a sus métodos de prueba un nombre que describa lo que está probando. Es decir. los tres testcases contenidos en su ContainsItem() se convierten en: containsReportsFalseIfTheItemHasNotBeenAdded(), containsReportsTrueIfTheItemHasBeenAdded(), containsReportsFalseIfTheItemHasBeenAddedThenRemoved(). Encuentro que forzarme a pensar en un nombre descriptivo como ese me ayuda a conceptualizar lo que tengo que probar antes de codificar la prueba real.

3. Si hace TDD, debe escribir sus primeras pruebas y solo agregar código a su implementación cuando tenga una prueba que falla. Incluso si no lo hace, le dará una idea de cuántas pruebas son suficientes. Alternativamente, use una herramienta de cobertura. Para una clase simple como un contenedor, debe apuntar a una cobertura del 100%.