Recientemente he estado experimentando con TDD mientras desarrollaba una aplicación GUI en Python. Me resulta muy tranquilizador tener pruebas que verifiquen la funcionalidad de mi código, pero ha sido difícil seguir algunas de las prácticas recomendadas de TDD. A saber, escribir pruebas primero ha sido difícil. Y me resulta difícil hacer que mis pruebas sean legibles (debido al uso extensivo de una biblioteca burlona).Prueba del código GUI: ¿debería usar una biblioteca de burla?
Elegí una biblioteca burlona llamada mocker. Lo uso mucho porque gran parte del código que estoy probando hace llamadas a (a) otros métodos en mi aplicación que dependen del estado del sistema o (b) objetos ObjC/Cocoa que no pueden existir sin un bucle de evento, etc.
de todos modos, tengo una gran cantidad de pruebas que se ven así:
def test_current_window_controller():
def test(config):
ac = AppController()
m = Mocker()
ac.iter_window_controllers = iwc = m.replace(ac.iter_window_controllers)
expect(iwc()).result(iter(config))
with m:
result = ac.current_window_controller()
assert result == (config[0] if config else None)
yield test, []
yield test, [0]
yield test, [1, 0]
Tenga en cuenta que esto es en realidad tres pruebas; todos usan la misma función de prueba parametrizada. Aquí está el código que se está probando:
def current_window_controller(self):
try:
# iter_window_controllers() iterates in z-order starting
# with the controller of the top-most window
# assumption: the top-most window is the "current" one
wc = self.iter_window_controllers().next()
except StopIteration:
return None
return wc
Una de las cosas que he notado con el uso de burlador es que es más fácil escribir el código de la aplicación en primer lugar y luego volver y escribir las pruebas en segundo lugar, ya que la mayoría de la tiempo me estoy burlando de muchas llamadas a métodos y la sintaxis para escribir las llamadas simuladas es mucho más detallada (por lo tanto, más difícil de escribir) que el código de la aplicación. Es más fácil escribir el código de la aplicación y luego modelar el código de prueba de eso.
Me parece que con este método de prueba (y un poco de disciplina) puedo escribir código fácilmente con una cobertura de prueba del 100%.
Me pregunto si estas pruebas son buenas pruebas? ¿Me arrepentiré de haberlo hecho así cuando finalmente descubro el secreto para escribir buenas pruebas?
¿Estoy violando tanto los principios básicos de TDD que mi prueba es en vano?