Digamos que estás escribiendo un estilo TDD de juego Yahtzee. Desea probar la parte del código que determina si un conjunto de cinco tiradas de dados es o no una casa completa. Hasta donde sé, cuando haces TDD, sigues estos principios:
- Escribe las pruebas primero
- Escribe lo más simple posible que funcione
- Refinar y refactorizar
Entonces, una prueba inicial podría verse así:
public void Returns_true_when_roll_is_full_house()
{
FullHouseTester sut = new FullHouseTester();
var actual = sut.IsFullHouse(1, 1, 1, 2, 2);
Assert.IsTrue(actual);
}
Al seguir "Escribe lo más simple posible que funcione", ahora debes escribir el IsFullHouse
método de esta manera:
public bool IsFullHouse(int roll1, int roll2, int roll3, int roll4, int roll5)
{
if (roll1 == 1 && roll2 == 1 && roll3 == 1 && roll4 == 2 && roll5 == 2)
{
return true;
}
return false;
}
Esto da como resultado una prueba verde pero la implementación está incompleta.
¿Debería realizar una prueba unitaria de todas las combinaciones válidas posibles (tanto de valores como de posiciones) para una casa completa? Esa parece ser la única forma de estar absolutamente seguro de que su IsFullHouse
código está completamente probado y correcto, pero también parece bastante loco hacerlo.
¿Cómo probarías la unidad algo como esto?
Actualizar
Erik y Kilian señalan que el uso de literales en la implementación inicial para obtener una prueba verde podría no ser la mejor idea. Me gustaría explicar por qué hice eso y esa explicación no cabe en un comentario.
Mi experiencia práctica con las pruebas unitarias (especialmente usando un enfoque TDD) es muy limitada. Recuerdo haber visto una grabación de TDD Masterclass de Roy Osherove en Tekpub. En uno de los episodios construye un estilo TDD de Calculadora de Cuerdas. La especificación completa de la calculadora de cadenas se puede encontrar aquí: http://osherove.com/tdd-kata-1/
Comienza con una prueba como esta:
public void Add_with_empty_string_should_return_zero()
{
StringCalculator sut = new StringCalculator();
int result = sut.Add("");
Assert.AreEqual(0, result);
}
Esto da como resultado esta primera implementación del Add
método:
public int Add(string input)
{
return 0;
}
Luego se agrega esta prueba:
public void Add_with_one_number_string_should_return_number()
{
StringCalculator sut = new StringCalculator();
int result = sut.Add("1");
Assert.AreEqual(1, result);
}
Y el Add
método se refactoriza:
public int Add(string input)
{
if (input.Length == 0)
{
return 0;
}
return 1;
}
Después de cada paso, Roy dice "Escribe lo más simple que funcionará".
Así que pensé en probar este enfoque al intentar hacer un juego Yahtzee estilo TDD.
if (roll1 == 1 && roll2 == 1 && roll3 == 1 && roll4 == 2 && roll5 == 2)