TDD
Valentin Starck
metodología? Es realmente ventajosa?
Juan Ignacio Dopazo
Enciendo la polémica. Alguno de uds trabaja/trabajo bajo esta
metodología? Es realmente ventajosa?
Valentin Starck
Realmente no me termina de convencer...
Juan Ignacio Dopazo
joseanpg
intento más de alcanzar la panacea "robótica" en el mundo del
software.
jneira
Test funcional:
def "Proceso: filtrado parcial de los elementos del listado"(){
given:"Estamos en la pagina del inventario"
to InventarioPage
and: "Al consultar sin informar el filtro nos lista algun elemento"
def numElemsDefault=listado.elementos.size()
assert numElemsDefault > 0
when: "Informarmos los campos del filtrado y pinchamos en consultar"
filtro.rellenar(data)
filtro.consultar.click()
then: "EL numero de elementos filtrados tiene que ser igual o menor"
listado.elementos.size() <= numElemsDefault
where: data << getFormData()
}
y otro unitario:
def "Recuperacion de los envases por su ubicacion mas reciente"() {
given: "Un lote previo con envases que han cambiado de ubicacion"
def previo=save(entidadValida)
def todosEnvases=addEnvases(previo)
def todosEnvasesPorNumero=todosEnvases.groupBy {it.numero}
assert todosEnvasesPorNumero.values().any {it.size>1}
when: "Recuperamos los envases en la ubicacion mas reciente"
def envasesEnUltimaUbicacion=previo.getEnvasesEnUltimaUbicacion().groupBy {it.numero}
then: "Estaran todos los envases"
todosEnvasesPorNumero.keySet()==envasesEnUltimaUbicacion.keySet()
and: "Solo habra un envase por numero"
envasesEnUltimaUbicacion.values().every {it.size==1}
and: "Contendra el envase con la fecha de entrada en la ubicacion mas reciente"
todosEnvasesPorNumero.each {k,v->
assert envasesEnUltimaUbicacion[k][0]== v.max {it.fechaEntradaUbicacion}
}
}
No se que os parece el estilo bdd pero tiene la ventaja que te sirve de documentacion del codigo.
En cuanto a la valoracion de que me ha aportado y que no, lo dejo para otro momento que debo retirarme
Valentin Starck
Realmente se me complica pensar en como integraría estas metodologías en mi trabajo diario ya que practicamente trabajo sin requerimiento y sobre un proyecto mitad legacy/mitad desarrollo nuevo.
Para mi proximo proyecto voy a tratar de usar TDD.
--
Valentin Starck
blog.aijoona.com
Juan Ignacio Dopazo
On Thursday, October 13, 2011, Valentin Starck <valenti...@gmail.com> wrote:
> Esperare el feedback.
"
+1
Yo sigo sin estar convencido. Reconozco l valor de los tests. Hoy escribí uno. Pero de ahí a TDD...
Empece una librería chiquita para armar scripts de build en Node http://github.com/juandopazo/glue. Todavia no escribí tests porque realmente no tenia idea de como quería que quede entonces primero experimenté. Ahora que tengo una idea voy a escribir tests y veré como evoluciona.
Juan
gnz/vnk
comentaré. Pero en general, TDD como metodología personal, en que tú
mismo vas y defines unos tests y desarrollas a partir de ellos (dicho
así muy resumidamente) me parece igual de válido y de peligroso que
otras varias metodologías.
Me explico. Es muy muy fácil aplicar el *proceso* de TDD y sentir una
sensación de seguridad que no se corresponde ni mucho menos con la
realidad. Y sí, sí, también se puede hacer /bien/, no lo dudo. Pero he
visto muchos que se suponen experimentados, que conocen bien la
metodología, que llevan tiempo aplicándola o incluso explicándola, y
que caen en problemas (imho graves) de seguridad injustificada y
fragilidad real. Porque aplicar el *proceso* es, como decía, muy
fácil. Pero a la vez, es muy fácil aplicarlo sin ir más allá del
proceso en sí. Me puedo hacer un test, pasarlo, otro, pasarlo, otro,
pasarlo, etc, y terminar teniendo un 50% de tests completamente
innecesarios y una implementación que sigue siendo frágil.
Por otra parte, veo BDD más interesante. Por un lado me parece subir
un nivel de abstracción y pasar a, como dice Javier, diseñar más bien
una documentación o una especificación. Es más, me gustaría más BDD si
además se le añadiera la práctica de que esa especificación sea como
mínimo, "revisable" por cualquiera (i.e. una persona que no programa)
y sirviera de /contrato/. Que fuera el documento sobre el que se
negocia la funcionalidad (aunque quizá no fuera el único).
Es decir, que no me importaría reunirme con el
cliente/responsable/jefe/loquesea y usar esto (o algo de este estilo)
como guía:
def "Proceso: filtrado parcial de los elementos del listado"(){
given:"Estamos en la pagina del inventario"
and: "Al consultar sin informar el filtro nos lista algun elemento"
when: "Informarmos los campos del filtrado y pinchamos en consultar"
then: "El numero de elementos filtrados tiene que ser igual o menor"
}
De cualquier modo, y a modo de aviso sobre mi postura sobre algunos
temas, para que nos vayamos conociendo xD:
Yo tiendo a ser (al menos en mi cabeza) más artístico que ingeniero.
Hay toda una serie de metodologías y procesos que, simplemente, veo ir
pasando ante mi con los años pero muy pocos los veo que /duren/. Esto
no quiere decir que no aprecie practicar algunas *disciplinas
personales*, por supuesto. Pero en general, lo que nunca apreciaré es
ningún proceso, metodología o práctica, que se base en una aplicación
rígida y estricta de un principio o una serie de reglas sin más.
jneira
- http://fitnesse.org/FitNesse.UserGuide.OneMinuteDescription
- http://martinfowler.com/bliki/SpecificationByExample.html
jneira
- No es suficientemente agil cuando estas explorando, ya sea las herramientas que tienes por debajo o las diferentes posibilidades de diseño e implementacion de un componente, modulo o fragmento de codigo. Inevitablemente, aunque empezara haciendo primero los tests en cuanto llegas a un terreno no conocido te tiras a la consola o al cambio dinamico de la aplicacion en ejecucion o a rapidos scripts de usar y tirar.
- No te guia por arte de magia a hacer mejor codigo. Eso lo tengo clarisimo. Puede ayudarte y acompañar a las ideas o principios con los que te sientas a picar pero solo por hacer tests esos principios no van a aparecer en tu mente. No consigue hacer surgir un diseño de la nada aunque puede ayudar, de la misma manera que escribir una idea te ayuda a darle forma, mejorarla y rechazarla si no vale (aunque tambien empeorarla)
- Muchas veces supone una violacion flagrante del DRY ya que duplicas aunque sea en parte la logica del codigo real que estas probando. Si no tienes cuidado es todavia peor y te pasas mas tiempo cambiando los tests para que se adecuen al nuevo codigo que escribiendolo (suponiendo que ya no estas haciendo los tests primero). Esto hasta cierto punto es inevitable (por ejemplo con el cambio de nombres de vars o funs) pero se pueden hacer de forma que se evite lo maximo posible.
- Los tests no evitan 1, que la aplicacion no haga lo que tiene que hacer y 2, que tenga errores, ya que los tests dependen, obviamente, de los datos de entrada y de qué se comprueba en la salida y se puede fallar en ambas partes con lo que el test no hace bien su trabajo. Entonces el codigo real se convierte en el codigo que testea a los tests y la cosa se pone un poco kafkiana.