El caso es que he copipegado código del ejemplo de editor multipáginas que viene con Eclipse y también del WicketBench (un plugin para trabajar con Wicket del que pretendo plagiar más de una idea). Y resulta que este código “heredado” hace un uso bastante prolijo de métodos estáticos para obtener información de contexto y, sobre todo, de la plataforma. Y me viene al pelo el reciente artículo de Misko Hevery donde explica por qué los métodos estáticos son tan malos para las pruebas y delatan diseños deficientes.
En resumen: no tengo pruebas unitarias de mi código porque no puedo sustituir las llamadas a métodos estáticos por ningún tipo de doble. Cualquier colaborador puedo sustituirlo más o menos fácilmente con un doble (p.ej. un mock), pero un método estático está pegado “a fuego” a una clase, y no puedo sustituir una clase por otra… 🙁
Claro está que estoy cambiando el código para encapsular las llamadas a métodos estáticos en clases de colaboración que pueda sustituir en mis pruebas. Así acoto el problema, tal y como Eric Evans aconseja al explicar el “anticorruption layer” (capa anticorrupción), y mejoro la facilidad para escribir pruebas para mi diseño y, por tanto, mejoro también mi diseño.