Ahora que ya hemos definido completamente el comportamiento esperado de nuestras funciones de conversión, vamos a hacer algo un poco inesperado: vamos a escribir una batería de pruebas que ponga estas funciones contra las cuerdas y se asegure de que se comportan de la manera en que queremos. Ha leído bien: va a escribir código que pruebe código que aún no hemos escrito.
A esto se le llama pruebas unitarias (unit testing), ya que el conjunto de dos funciones de conversión se puede escribir y probar como una unidad, separado de cualquier programa más grande del que pueden formar parte más adelante. Python dispone de infraestructura para hacer pruebas unitarias: el módulo unittest, de nombre bastante apropiado.
 |
|
| unittest está incluido en Python 2.1 y posteriores. Los usuarios de Python 2.0 pueden descargarlo de pyunit.sourceforge.net. | |
La prueba unitaria es una parte importante de una estrategia de desarrollo centrada en las pruebas. Si escribe pruebas unitarias, es importante hacerlo pronto (preferiblemente antes de escribir el código que van a probar) y mantenerlas actualizadas con los cambios de código y de requisitos. Las pruebas unitarias no sustituyen a pruebas de mayor nivel funcional o de sistema, pero son importantes en todas las fases de desarrollo:
- Antes de escribir código, le fuerzan a detallar los requisitos de una manera útil.
- Mientras escribe el código, evitan un exceso de funcionalidad. Cuando pasan todos los casos de prueba, la función está completa.
- Cuando se hace refactorización de código, le aseguran que la nueva versión se comporta de la misma manera que la antigua.
- Cuando mantiene código, le ayuda a cubrirse las espaldas si alguien viene gritando que el último cambio hace fallar código ajeno (“Pero señor, todas las pruebas unitarias habían pasado correctamente antes de enviarlo...”)
- Cuando escribe código en equipo, aumenta la confianza en que el código que está a punto de enviar no va a romper el de otras personas, porque puede ejecutar las pruebas unitarias de ellos antes. (He visto este tipo de cosas en momentos de prisas. Un equipo divide y asigna la tareas, todo el mundo toma los requisitos de su tarea, escribe pruebas unitarias y luego las comparte con el resto del equipo. De esa manera, nadie va demasiado lejos desarrollando código que no juegue correctamente con el de otros).