Al hacer TDD y escribir una prueba unitaria, ¿cómo se resiste el impulso de "hacer trampa" al escribir la primera iteración del código de "implementación" que está probando?
Por ejemplo:
necesito calcular el factorial de un número. Comienzo con una prueba unitaria (usando MSTest) algo como:
[TestClass]
public class CalculateFactorialTests
{
[TestMethod]
public void CalculateFactorial_5_input_returns_120()
{
// Arrange
var myMath = new MyMath();
// Act
long output = myMath.CalculateFactorial(5);
// Assert
Assert.AreEqual(120, output);
}
}
Ejecuto este código y falla ya que el CalculateFactorialmétodo ni siquiera existe. Entonces, ahora escribo la primera iteración del código para implementar el método bajo prueba, escribiendo el código mínimo requerido para pasar la prueba.
La cuestión es que continuamente tengo la tentación de escribir lo siguiente:
public class MyMath
{
public long CalculateFactorial(long input)
{
return 120;
}
}
Esto es técnicamente correcto, ya que realmente es el código mínimo requerido para hacer que esa prueba específica pase (ir verde), aunque es claramente un "truco" ya que realmente ni siquiera intenta realizar la función de calcular un factorial. Por supuesto, ahora la parte de refactorización se convierte en un ejercicio para "escribir la funcionalidad correcta" en lugar de una verdadera refactorización de la implementación. Obviamente, agregar pruebas adicionales con diferentes parámetros fallará y forzará una refactorización, pero debe comenzar con esa prueba.
Entonces, mi pregunta es, ¿cómo logras ese equilibrio entre "escribir el código mínimo para pasar la prueba" mientras lo mantienes funcional y en el espíritu de lo que realmente estás tratando de lograr?