La práctica de “test driven development” (“desarrollo guiado por pruebas”) nos obliga a “pulir” nuestras habilidades para crear pruebas unitarias y permite que nuestro código esté mejor documentado y los requerimientos bien definidos.
En esta publicación reciente puede verse una definición de pruebas unitarias.
Click aquí para una versión accesible de la infografía (apta para lectores electrónicos)
Es un proceso de desarrollo de software en el cual se comienza por escribir pruebas para la funcionalidad a desarrollar (generalmente, en forma de “unit tests”) y luego se escribe el código necesario para que esas pruebas corran exitosamente.
Ejemplo – Si se debiera desarrollar la siguiente funcionalidad:
Dado un entero n (mayor que 1), retornar un arreglo de strings -indizado desde 1- donde:
arreglo[i] == “FizzBuzz” si i es divisible por 3 y por 5.
arreglo[i] == “Fizz” si i es divisible por 3.
arreglo[i] == “Buzz” si i es divisible por 5.
arreglo[i] == i si ninguna de las anteriores es verdadera.
Podrían crearse pruebas como estas:
Entrada: n=1. Salida esperada: [“1”]
Entrada: n=3. Salida esperada: [“1”, “2”, “Fizz”]
Entrada: n=15. Salida esperada: [“1”, “2”, “Fizz”, “4”, “Buzz”, “Fizz”, “7”, “8”, “Fizz”, “Buzz”, “11”, “Fizz”, “13”, “14”, “FizzBuzz”]
Una prueba donde n=0 sería inválida, ya que la especificación tiene la precondición de que n sea mayor que 1.