Pruebas automáticas con FTP
0. Índice de contenidos.
1. Basado en hechos reales:
Esta frase, queridos amigos, nos ha perseguido durante muchos años a los profesionales del desarrollo de software:
No toques ese código no se vaya a romper, además, eso lo hizo Federico que ya no está.
Cambiad Federico (que se ha ido al cielo de los programadores, como decía un antiguo jefe mío cuando un compañero cambiaba de proyecto o se marchaba a otra empresa) por el nombre que corresponda y seguro que esa frase estará oculta por ahí en algún rincón de vuestra memoria.
Y es que no hay nada que asuste más a un desarrollador de Software que romper algo que ya funcionaba, por lo que en lugar de refactorizar algo cuando es necesario, pues solemos optar por alternativas menos adecuadas basadas en patrones muy conocidos como: CPCI (Copy Paste and change it) combinándolo con LTIAGFUT (Look, there is a goat floating up there).
Entonces, uno como el que os escribe, que ya va para viejuno y ha provocado por tanto muchos desaguisados, ha aprendido con sangre, que las pruebas automáticas no deberían ser una opción.
Echando una manita en un proyecto, la primera historia que cayó en mi tejado fue ampliar la funcionalidad de una clase que hacía las veces de adaptador (wrapper) sobre una librería FTP. Bueno, pues eso, que uno empieza a mirar y descubre que el código pide una refactorización para poder ampliar la funcionalidad de manera adecuada y para corregir alguna que otra cosita. Pero no pasa nada porque tengo tests… o no … pues eso que no… que no tengo, no había tests de esta parte… y ¿ Por qué no hay ?, me pregunté… supongo que ya más o menos os imagináis la respuesta: básicamente porque es un wrapper sobre FTP y como vamos a montar los tests si necesito un servidor FTP, etc… y entonces, vuelvo a oir esa frase tan vieja como la siesta surgiendo desde mi propio inconsciente: Paco, no toques ese código no se vaya a romper. Pues esto es como dejar de fumar: hay que superar ese momentito en el que consideras que la solución a todos tus problemas es echarte un cigarrito. Supéralo y móntate los tests adecuados. Si miras un poco por internet resulta que hay gran cantidad de frameworks que facilitan el trabajo. 5 minutos me llevó encontrar esto: MockFtpServer. Esta librería nos permite simular un servidor FTP con lo que poder realizar nuestros tests automáticos.
2. Ejemplo:
La documentación del site es muy buena y la librería es muy intuitiva por lo que no me voy a extender demasiado:
Para incluir la dependencia si usais maven:
org.mockftpserver MockFtpServer 2.4 test
Para levantar un servidor FTP para vuestras pruebas si usais JUnit:
@BeforeClass public static void startFTPServer() { FakeFtpServer fakeFtpServer = new FakeFtpServer(); fakeFtpServer.setServerControlPort(FTP_PORT); fakeFtpServer.addUserAccount(new UserAccount("usuario", "password", "c:\\data")); FileSystem fileSystem = new WindowsFakeFileSystem(); fileSystem.add(new DirectoryEntry("c:\\data\\pruebas")); fakeFtpServer.setFileSystem(fileSystem); fakeFtpServer.start(); }
3. Conclusiones:
Cumplir los principios F.I.R.S.T (Fast.Isolated.Repeatable.Self-validating.Timely) a veces es complicado; los cuatro primeros son duros de conseguir cuando tenemos que interactuar con herramientas externas (servidores de correo, servidores FTP, bases de datos, sistemas de autorización…), es decir, cuando nos salimos del límite del sistema. Sin embargo existen gran cantidad de herramientas que nos facilitan esa labor haciendo de Fake y que proporcionan un mecanismo para evitar esa vieja excusa de «esto no se puede probar».
Muy bueno…hace un par de años tuve que usar maquinas virtuales con Linux para hacer mis pruebas de FTP.