Cruzada contra la Waterfall Alliance
Este es un mail que escribi hace un tiempo y como me gusto decidi colgarlo aca. No tienen nada novedoso y es un tema que deberia estar sepultado pero… en fin.
Metodología en Cascada
- La primera vez que aparecio un diagrama parecido a lo que se conoce como metodologia en cascada fue en el paper “Managing the development of large software systems” de Winston Royce. Ahi se lo pone como ejemplo de UN MODELO QUE NO FUNCIONA para desarrollos grandes.
- La metodologia en cascada da una falsa sensacion de seguridad. En la cual podemos predecir facilmente lo que va a pasar de aqui a dos meses, seis o varios años. Es la bola de cristal de la ingenieria del software!
La metodologia es muy sencilla de explicar a los clientes. (por experiencia les digo que no es facil explicar RUP a un cliente). Y lo que es peor, es muy facil de entender para los lideres de proyecto! (en cambio, cuantas dudas les aparecieron al interpretar SCRUM?)
- En definitiva es como una bola de cristal, muy sencilla de operar, pero que rara vez da el resultado esperado.
La metodologia en cascada NO AYUDA AL USUARIO A REALIZAR TRAZABILIDAD DE SU PROYECTO! piensenlo: finaliza el analisis y al usuario le muestro miles de papeles con informacion QUE EL YA CREE CONOCER en la cual esta plasmado su negocio. Cuatro meses despues aparecemos con el cliente mostrandole cientos de diagramas, que no entiende, donde figura desde la arquitectura general de su sistema hasta el diseño detallado de cada clase. Mientras tanto, el diseñador/arquitecto es un ser de infinita sabiduria que tiene el sistema perfecto en papel, pero que aun no fue probado en la practica. Luego de que el usuario ve cientos de diagramas que no entiende desaparecemos por seis largos meses durante la construccion del sistema y… ustedes entienden la idea. Comparenlo con prototipado o implementaciones sucesivas en el que todas las semanas le doy algo al usuario que puede ver y palpar, probar y darme feedback. El usuario percibe valor y se da una idea de donde esta yendo a parar su dinero.
- Las primeras implantaciones serias de la metodologia en cascada las realizo el departamento de defensa de estados unidos, parafraseando a groucho marx “inteligencia militar son dos terminos opuestos”.
- Desde ya que la metodologia tiene sus aplicaciones, limitadas pero aplicaciones al fin, pero no hay que dejarse llevar tan facilmente por las luces de colores de la facilidad de adopcion y sensacion de control que nos muestra al principio.
ServiceConstructionException: Could not find definition for service
Ok… just for the record, Al implementar un client ws con cxf tener cuidado de no estar usando un frontend proxy factory en lugar de un jaxws proxy factory como, en general, queremos.
JaxWsProxyFactoryBean factory = new JaxWsProxyFactoryBean();
factory.getInInterceptors().add(new LoggingInInterceptor());
factory.getOutInterceptors().add(new LoggingOutInterceptor());
factory.setServiceClass(MyService.class);
factory.setAddress("http://localhost/ws");
MyService client = (MyService) factory.create();
String.format en Javascript
Dejo a continuacion una funcion bastante util que se comporta como el String.format de Java. En Javascript es comun andar componiendo strings a partir de constantes, variables, literales y otras cosas para generar una salida HTML. Asi que en lugar de escribir:
var v = "<span style='color:"+myColor+"'>"+singleton.myText()+"</span><span id='"+entityId+"'>"+Text+"</span>";
podemos poner:
var v = "<span style='color:{0}'> {1} </span> <span id='{2}'>{3}</span>".format(myColor,singleton.myText(),entityId,Text);
más lindo no?
// Replaces {0},{1},{n} with the arguments.
String.prototype.format = function() {
var i = 0;
var string = (typeof (this) == "function" && !(i++)) ? arguments[0] : this;
while(i < arguments.length) {
string = string.replaceAll('\\{' + i + '\\}', arguments[i]);
i++;
}
return string;
}
EasyMock: Mocks… eh… fácil.
El TDD es muy lindo hasta que nos toca hacer un test unitario a un componente que tiene muchas dependencias, que en estos tiempos de arquitecturas multitier suelen ser la mayoria.
Estas dependencias suelen remplazarse por objetos que simulan ser los reales compartiendo la misma interfaz. Claro que es solo una fachada, su implementación dista mucho de ser la real, pero nos proporcionan un comportamiento determinista y controlado contra el que probar nuestros componentes. EasyMocks es un framework que permite crear estos objetos de forma muy sencilla indicando cual es la interfaz que deben cumplir y cual es el comportamiento que esperamos.
Creando el Mock
Lo primero que necesitamos es decirle al framework cual va a ser la interfaz que queremos implementar en nuestro “mock”. Supongamos que necesitamos testear una clase Cliente que necesita los favores de una clase que implemente Servicio. Lo que vamos a hacer es un “mock” que simule ser una implementacion real de Servicio pero solo la vamos a usar para llevar a cabo el test.
El metodo estatico createMock de la clase EasyMock toma una Interface como parametro (tambien puede ser una clase) y nos devuelve un objeto que la implementa.
Servicio servicioMock = EasyMock.createMock(Servicio.class)
Its Alive!!
Genial, ¿Ya podemos pasarle la referencia servicioMock al Cliente y testear a gusto?… bueno… no tan easy.
A continuacion vamos a hacer que ese servicioMock implemente la operacion sumarDiez que, a partir de un parametro int numero devuelve ese numero incrementado en 10. No va a ser la implementacion real, solo a ’simular’ que esta haciendo algo realmente mediante el metodo EasyMock.expect.
EasyMock.expect(servicioMock.sumarDiez(5)).andReturn(15);
Acabamos de decirle a nuestro servicioMock que cuando alguien invoque al metodo sumarDiez con el numero 5 como parametro el debe devolver 15. No hay implementacion real, solo se pretende estar realizando la operacion. Ademas nuestro mock no sabe que hacer si alguien le pasa el numero 6 como parametro, y nos lo hara saber con una hermosa excepción.
Easymock.replay(servicioMock);
Esto pone al mock en ‘test mode’ indicando que ya podemos usarlo para nuestro test.
Still alive… and well?
Ahora sí podemos meter el servicioMock en nuestro test y admirar a EasyMock en toda su gloria
Ojo que lo que estamos testeando es el comportamiento de Cliente y no de Servicio! es decir que invocarAlMetodoSumarDiezDeServicio() este delegando correctamente e invocando a Servicio.
Cliente cliente = new Cliente();
cliente.setServicio(servicioMock);
int esultado = cliente.invocarAlMetodoSumarDiezDeServicio(10);
assertEquals(15,resultado);
Las posibilidades que tiene Easymock son ilimitadas y podemos simular comportamientos extremadamente complejos. Pueden encontrar mas informacion sobre todo el potencial de EasyMock en su página oficial.
