Via Navegapolis descubro una nueva utilidad para mejorar la eficiencia del proceso de testing. Se trata de Jumble, una herramienta que permite medir la efectividad de los tests unitarios que hayamos escrito.
La idea es clara. Seguro que como yo, algunos habréis tenido la sensación después de terminar los unit tests de que quizás no sean tan completos como os gustaría, e incluso cuando la herramienta de cobertura de código (code coverage) te dice que la cobertura es buena, tu tienes esa sensación de que hay maneras de entrar en el programa que no has cubierto con unit tests.
Lo que hace Jumble es mutar el código de tus clases y después ejecutar los unit tests. Como ha mutado las clases, lo que Jumble espera es que los unit tests sean capaces de detectar esa mutación y alerten de que la entrada es inválida, y por lo tanto fallen. En caso de que los unit tests no fallen pues es probable que ese caso en concreto no haya sido cubierto.
Las mutaciones son de lo más diversas, por ejemplo cambiar sentencias condicionales (e.g. x > y pasa a ser !(x>y)) o por ejemplo cambiar el valor de las constantes definidas en el código, o modificar operaciones aritméticas. Para mutar el código Jumble utiliza la librería BCEL y modifica el bytecode en tiempo de ejecución.
El concepto me ha parecido realmente interesante. Me parece una aplicación bastante inteligente a la modificación de código fuente. En fin, que en el video sobre Model Based Testing que nos recomienda Juan Palacio hablan un poco sobre ello y muestran algún ejemplo.
jueves, septiembre 06, 2007
Suscribirse a:
Enviar comentarios (Atom)
Subscríbete al feed
Regístrate con Feedburner y recibirás por email todas las novedades
Comentarios Recientes
Recent Comments
Etiquetas
- programación (190)
- Arquitectura (90)
- java (78)
- Otros (76)
- empresa (62)
- sistemas (61)
- escalabilidad (56)
- agile (54)
- emprendedores (48)
- Irlanda (42)
- Open Source (31)
- google (27)
- empleo (26)
- humor (24)
- amazon (22)
- eventos (22)
- metodologías (22)
- fun (21)
- rendimiento (21)
- software (21)
- dublin (20)
- testing (18)
- startups (17)
- galicia (15)
- hadoop (15)
- spring (15)
- datacenter (14)
- seguridad (14)
- unit testing (14)
- web 2.0 (14)
- cloud computing (13)
- grails (13)
- jobsket (13)
- libros (13)
- Ingeniería (12)
- eclipse (12)
- facebook (12)
- bases de datos (11)
- virtualización (11)
- yahoo (11)
Archivo de Entradas
-
►
2011
(58)
- ► septiembre (5)
-
►
2009
(61)
- ► septiembre (3)
-
►
2008
(129)
- ► septiembre (11)
-
▼
2007
(217)
-
▼
septiembre
(17)
- Pequeños cambios en el blog
- Comunicando ideas con comics
- Las empresas europeas buscan soluciones en Polonia
- Bug Driven Development
- Google rebaja la latencia bajo el agua
- Lotus Symphony, Eclipse RCP y Open Source
- El rol de build engineer
- Eclipse y su infraestructura de testing
- WebLogic se prepara para JEE 6
- Un par de eventos sobre programación en Dublin
- Validación en Java: Oval, una joya escondida
- ¿Debería un arquitecto programar?
- Rich Ajax Platform
- delicious 2.0
- Probando la eficiencia de los tests unitarios
- High performance web sites: 13 reglas para consegu...
- ¿feature o bug?
-
▼
septiembre
(17)
Mi CV
Cosas que leo
List
También tenemos una tienda de Colchones y Sofás en Betanzos
comments
6 Respuestas a "Probando la eficiencia de los tests unitarios"1:00
Lo de la mutación del código para pruebas lleva tiempo dándose vueltas.
Otra herramienta en la misma línea es Jester.
En el lado comercial, tienes las herramientas de Agitar Software. Hace tiempo vi una demo y creo que también usaban algo de mutación de código.
Saludos
JM
10:07
Gracias por la información JM.
No conocía tampoco Jester, tiene buena pinta.
1:19
Las herramientas de Agitar son impresionantes. Nosotros hicimos alguna prueba y los resultados son espectaculares.
Sólo hay dos problemas: el precio (carisimo) y el esfuerzo inicial de configuración.
9:57
Ferrán,
Me pica la curiosidad. Caro es ¿miles de euros por usuario?, o ya entramos en dos cifras...
y ¿Por qué es tan problemática la configuración?
23:59
Martín,
El producto lo licencian o bien por usuarios o bien por java classes. En el primer caso, según precio de catalogo, estamos hablando en miles de euros; en el segundo, en decenas de euros.
En nuestro caso, vimos dos problemas:
1) multiplica la licencia por mil usuarios o por miles de clases y la cifra que sale es espectacular;
2) la licencia es exclusivamente de alquiler anual, en vez de lo común de fee inicial y luego mantenimiento, lo que significa que cada año has de pagar esos miles de euros.
Respecto a la configuración, no es que sea problematica, es que requiere de un esfuerzo importante si quieres adaptarlo a un entorno corporativo.
14:31
No me extraña que lo hayáis descartado.
Lo de número de usuarios y clases aún puede pasar por eso de poderse negociar, pero lo de que la licencia sea anual. Vaya, eso mata realmente el producto, al menos cuando se está hablando de cantidades considerables de dinero.
Me hace considerar si el "target" de esta gente es realmente las grandes empresas.
Publicar un comentario