Publicado un nuevo número del podcast de javaHispano. Este podcast es la segunda parte del podcast sobre testing de aplicaciones java en el que participarán de nuevo Alfredo Casado, Julio César Pérez y Jose Luis Bugarin.
En el primer podcast se intento transmitir la importancia del testing y se dieron algunas recomendaciones generales, en esta segunda parte nos vamos a centrar más en las herramientas concretas de las que disponemos en la plataforma Java para dotar a nuestros proyectos de testing automático. Hablaremos sobre herramientas como jUnit, dbUnit o Selenium, discutiremos sobre la importancia de la integración continua como complemento indispensable de los test automáticos y mencionaremos frameworks que nos permiten escribir test de aceptación en un lenguaje más cercano al negocio como Fit/Fitnesse o concordion.
Links de interes:
Libros y documentación:
Etiquetas: otro, test, junit, dbunit, selenium, watir, fitnesse, concordion
Ante todo, felicidades por el podcast. Muy completito.
Respecto a los tests creo que hay una cosa que no habéis comentado (corregidme si me equivoco): con ellos comprobamos que la aplicación está bien, pero... ¿quién asegura que los tests están bien?
Con esta paradoja no intento desanimar a la gente, simplemente incidir en que hay que poner los 5 sentidos cuando codificamos tests.
Ah, y gracias por el enlace al plugin the Chuck Norris. Todo un descubrimiento.
Bueno haber, los tests, o la implementación de un plan de pruebas (en los casos más idílicos en los que se haga) también pueden fallar pero el hecho de realizar ejercicio mental de ver si algo que se ha desarrollado es correcto o no ya te hace incrementar las probabilidades de éxito (entiendase hacer las cosas bien)
--vilherda--
Donde esta la primera parte?
Haz clic en RSS Sindicación Podcast y verás todos los anteriores. La primera parte es el número 64.
Gracias, ya lo he escuchado. He echado de menos una referencia al BDD pero en general esta muy bien. Enhorabuena!
Ahora que está de moda el tema "ágil", con el TDD, integración contínua, etc. ¿alguien ha probado a usar gerrit (http://code.google.com/p/gerrit) o alguna otra herramienta que facilite la revisión de código?
Antes que nada, felicitar la acertada exposición de estos temas, tanto en la primera como en la segunda parte.
Sin embargo, por alimentar un poco la polémica, y en relación a la primera parte del podcast, recuerdo que se incidía varias veces en que no se puede denominar profesional al programador que no escriba tests automáticos. Me ha recordado a la falacia "No true Scotsman" (ver http://en.wikipedia.org/wiki/No_true_Scotsman y http://www.youtube.com/watch?v=_HJrAaGJudw). Me pregunto si John Carmack escribiría sus tests automáticos para los motores de sus juegos, o si Ken Thompson y Dennis Ritchie también escribieron tests automáticos cuando estaban escribiendo Unix, o tal vez no fueran verdaderos profesionales.
Buenas.
A mi me gustaría aclarar sobre la frase "no se puede denominar profesional" me gustaría comentar que es la opinión (y por supuesto respetable) de los que lo han manifestado. En lineas generales Profesional es aquel que cobra por su trabajo (haga lo que haga). Si puede vivir de ello es que lo hace bién.
Desde mi punto de vista, se puede tener un desarrollo profesional y con calidad sin test, pero dividiendo el proyecto en partes a ciertas personas que conozcan perfectamente como está y que sepan tocar el código sin romperlo.
Ahora bién, en este último caso tienes una dependencia muy alta sobre esta persona, si en algún momento dado esta persona está de baja o se va de la empresa posiblemente el que venga detras romperá cosas por desconocimiento.
Las metodologías ágiles manifiestan que el código es de todos, todo el mundo puede tocar cualquier parte para evitar estas dependencias tan fuertes y evitar islas de conocimiento, pero a su vez que la gente no tenga miedo de tocar algo utilizando test y mejorar la calidad de lo que se entrega.
(Esta es solo mi opinión. No es la verdad absoluta)
Saludos, Jorge
Hombre la gente que citas son grandes profesionales, mucho mejores que yo, así que no estoy en disposición de decir que no lo sean por que no escriban test automaticos. Aunque de todos modos citas desarrollos de hace bastantes años, somos una industria joven y se van enocontrando mejores formas de hacer las cosas, hoy en día pocos desarrollos de embergadura se afrontan sin una estrategia de testing automatico.
Dicho esto y poniendo las cosas en su contexto, el testing es una tecnica que mejora enormemente la calidad de cualquier de un desarrollo si se aplica correctamente, y en realidad no tenemos ninguna otra tecnica que permita asegurar la calidad de un desarrollo (demostrar matematicamente el funcionamiento de un programa no es algo viable), nos queda el testing manual y ya sabemos los problemas que tiene. Personalmente un desarrollador que no conozca y sepa aplicar testing automatico como una de sus habilidades basicas es alguien que tiene un deficit como profesional importante, aunque no se note mucho por que es un deficit desgraciadamente muy común, pero es un defict que debería tratar de corregir.
La idea no es "si no haces testing no eres un pofesional, no vales", es más bien una llamada de atención para que la gente ponga prioridad en aprender estas tecnicas y sea consciente de la importancia del tema. Si queremos ser tratados como profesionales lo primero es empezar a comportarse como tal, para empezar no estaría mal entregar programas que funcionen. Que en realidad de eso va el testing, hablamos de mejorar la calidad y tal, pero la cruda realidad es que de momento nos conformariamos con llegar al nivel de calidad "la aplicación funciona correctamente", es un objetivo modesto, pero por algún sitio habra que empezar a arreglar este desastre de industria.
y en realidad no tenemos ninguna otra tecnica que permita asegurar la calidad de un desarrollo
Y en realidad tener tests no asegura la calidad del desarrollo. Asegura que cumples los tests. Claro, si se aplica todo bien y se hacen los tests adecuados, por supuesto... pero puestos a suponer, si haces lo mismo con las pruebas manuales, también lo podrías asegurar. Así que podrías hablar de que es un método más eficiente y menos propenso a fallos, por ejemplo... pero eso de que es el único... es pasarse tres pueblos enteros.
A mi de este tema y similares lo que menos me gusta es el lenguaje extremista y todas esas "llamadas de atención". Si el tema lo vale por si mismo, no hacen falta llamadas de atención.
Y puestos a complementar, iluminemos todas las caras de la moneda:
Si el tema lo vale por si mismo, no hacen falta llamadas de atención.
Esa es tu opinión, yo considero que las llamadas de atención son necesarias y mucho. Estas tecnicas a día de hoy son desconocidas para mucha gente y hacer enfasis en su importancia no se que tiene de malo. Me parece bien la posición exceptica de no creerte lo que venga diciendo el primer "vendedor de crecepelo", supongo que sera cuestión de apreciación, pero donde tu ves "extremismo" te aseguro que lo único que hay es entusiasmo por transmitir una serie de tecnicas que personalmente creo que aportan muchisimo a la mejora de nuestra profesión.
Así que podrías hablar de que es un método más eficiente y menos propenso a fallos
Vamos que puede que yo me pase un poco, pero tu por llevar la contraria creo que te estas quedando más que corto. No es que el testing automatico sea "más eficiente" es que el costo del testing manual es prohibitivo si queremos hacerlo bien, es decir, probando todas y cada una de las funcionalidades de la aplicación en cada release (más aún si hacemos releases frecuentes, que es otro factor importante para la calidad de un proyecto, feedback frecuente del cliente). En realidad estamos hablando de dos alternativas separadas por un abismo, una vez superada la fase inicial de aprendizaje que necesita el testing automatico por supuesto.
@remoh : ni siquiera la demostración matemática sería suficiente: ¿cómo se garantiza que no se han cometido errores en los pasos de la demostración? ¿tal vez con un programa para verificar la demostración? ¿y quién garantiza que ese programa no contiene errores?... por tanto, efectivamente, no podemos hablar de garantías, sino de grados de confianza en la corrección del programa.
Si el coste del testing manual es prohibitivo y el automático te permite hacerlo, está claro que es más eficiente. No se donde está "el fallo" en la declaración, excepto en no ser tremendista, exagerada y "llamar la atención" ;).
Y sí, es mi vena exceptica pero lo que tu llamas entusiasmo es exactamente lo mismo que hacen los vendedores de crecepelo, así que si te basas sobretodo en eso, acabas siendo indistinguible de uno. A mi que si me intentan vender cualquier tecnología, o producto, a base de "entusiasmo" donde nunca hay "peros", lo solucionan todo sin excepcion, si no lo tienes/usas no eres nadie etc. etc. pues de primeras ya se me que me están mintiendo (TANSTAAFL) así que me entra la alergia. Y si se te ocurre intentar averiguar más de alguna afirmación dudosa, como lo de que lo solucionan todo siempre, entonces a la hoguera por traidor y hereje. Mismamente como las sectas.
Pero sí, ya se que es cosa mía. Todavía hay un montón de gente que se cree la publicidad de "tenemos los precios más baratos" de los folletos de los supermercados :).
Hola a todos.
Me alegra mucho que os haya gustado. Gracias por vuestros comentarios.
Intentaré contestar un poco.
@anónimo: lo que intentamos promover es la automatización del proceso de pruebas del desarrollo de software. Que sea automático, es indiferente de que sea eficaz.
¿Nos dedicamos a automatizar el negocio de otros y ponemos en duda automatizar el nuestro? Lo siento pero nunca ha ido conmigo el haz lo que yo diga, pero no lo que yo haga.
@supertorpe: sí que son ganas de polemizar. Leonardo DaVinci seguramente sería el arquitecto más profesional de su época y no usaba ningún programa cad ni complementarios. No tenía ni calculadora! En nuestro sector 30 años con Internet es un abismo. Sólo hay que comparar Mhz y Bytes.
Los genios que nombras (y muchos más) no han usado "testing" para crear sus obras. Pero estoy seguro que automatizaron en la medida posible su proceso de pruebas. Sería interesante escribirles para preguntarles que técnicas usaron.
@greeneyed: obviamente es nuestra opinión, fruto de nuestra circunstancia, criterio y experiencia. No pretendemos decirle a nadie cómo debe hacer su trabajo. Como dijo Jorge en la 1a parte, el podcast es una tertulia, no es un discurso ni un llamamiento.
Ojo porque TDD no es testing automático y ojo también, porque es cierto que el testing puede dar una "falsa" sensación de seguridad. Pero sólo tan "falsa" como cada uno se deje engañar a si mismo. Los tests sólo prueban lo que se les programa para que prueben. Pero prefiero la sensación de seguridad que me da una bateria de tests automatizados que conozco a que alguien me diga: sí, lo he montado, me he metido dentro de la pantalla y lo he probado.
@jcesarperez: No pretendemos decirle a nadie cómo debe hacer su trabajo.
No, algunos simplemente insultar, por que eso es lo que es cuestionar la profesionalidad de alguien, a los que no lo hacen igual :). Pero bueno, ya hemos quedado que es "figurativo" y sólo una llamada de atención, así que aportaremos otra: insultar o menospreciar a la gente a la que intentas convencer de algo no es la mejor manera de hacerlo ;).
Lo de "...seguro que automatizaron en la medida posible su proceso de pruebas..." parece un ejemplo literal del "No true Scotsman" que mencionaba supertorpe :)
De todas formas, estoy de acuerdo contigo en lo básico. Es simplemente la forma de mandar el mensaje, y no en tu caso personalmente si no en global, con la que estoy en desacuerdo.
Pues nada, tenemos opiniones distintas sobre como transmitir el mensaje, yo desde luego creo que hace falta ponerle mucho más entusiasmo y enfasis al asunto y sobra tanto comedimiento politicamente correcto.
De todos modos me interesa más el fondo que la forma, si a veces peco de excesivo entusiasmo es simplemente porque realmente creo en lo que hago, en lo particular estas tecnicas han echo que mejore como profesional como no lo había echo con ninguna otra y creo firmemente en sus beneficios, y como estoy entusiasmado por como han transformado para mejor mi forma de trabajar la forma de transmitirlo es igualmente entusiasta, es lo que pasa cuando uno aún conserva cierta pasión por su trabajo. Y desde luego no tengo ningún animo de insultar a nadie ni de vender ningún crecepelo porque como tu sabes perfectamente esto va de gratis.
Pero vamos entiendo que tengamos visiones distintas de como transmitir la idea así que te animo a que transmitas el mensaje como tu creas que es más adecuado que los microfonos están abiertos :P
Daniel eres "mu exagerao" :)
Tienes que entender el ardor misionero de Alfredo Isaías a veces lleva a ser poco correcto en el lenguaje (es lo que conlleva ser profeta), pero hay que reconocer que si acojemos buena parte del mensaje que predica Alfredo y compañeros (discípulos más bien) de tertulia redimiremos nuestros pecados de vagancia y falta de garantías de nuestro trabajo XD
@remoh: Pues nada, tenemos opiniones distintas sobre como transmitir el mensaje, yo desde luego creo que hace falta ponerle mucho más entusiasmo y enfasis al asunto y sobra tanto comedimiento politicamente correcto.
Jejeje, no pasa nada. También es lógico, si le pisas a alguien el pie llevado por las prisas, es lo normal que al que le pises el pié no le parezca bien y el que pisa no le de tanta importancia "por que es que tiene prisa". Al fin y al cabo no es su pie ;).
@jmarranz: Daniel eres "mu exagerao" :)...
A ver, tampoco nos la cojamos con pinzas. No estamos hablando de decir "los informaticos y las informaticas" por politica sexista mal entendida. Nos quejamos de "los de marketing" por que venden motos y vaporware y nos meten en cada lío que pa'que y ahora hacemos lo mismo que ellos, pero como lo hacemos nosotros y es "por entusiasmo" entonces vale, está bien.
Y lo digo con todo el "cariño" y las ganas de que el mensaje triunfe, pero si el mensaje lo sueltas así para convencer a los que se tragan cualquier cuento, mañana vendrá un vendedor de crecepelo, les soltará otra sandez con el mismo lenguaje y se los llevará a otra parte. Y si no basta ver lo que pasó con los applets, demasiado hype y demasiado pronto, SOA, hasta en la sopa y para todo, etc. etc. A los que has de convencer es a los que cuando tengas convencidos estarán a tu lado con convicción. Y si a esos no los puedes convencer es que quizá no tengas razón o no lo sepas hacer.
En Praga en TheServerSide Symposium estuve en una charla de un framework, supuestamente muy bueno pero que usa poca gente, en la que en un momento dijo, literalmente, "es que los que no lo usan son imbeciles", con sonrisita y tal, pero la verdad es que yo diría que la temperatura bajo 2 grados de golpe cuando lo dijo y el sonido se paró unos segundos. En una sala llena de tios que no lo usan, por que la charla era de introduccion, y nos llama a todos "imbéciles"!! Por supuesto que no era literal ni nada parecido, pero "llevado por el entusiasmo" se puso en un segundo a la mayoría del auditorio a la defensiva. Y casi toda la charla tenia ese aire "es que hacerlo de otra forma no tiene sentido", "así es como se deben hacer las cosas..." etc. etc.
Total, cuando acabó me quedó una idea muy muy clara de, entre otras cosas, por qué no había mucha más gente que lo usara :).
Y sí, ya se que yo soy muy raro pero es que los del canal teletienda también tienen mucho entusiasmo y usan argumentos parecidos, a veces incluso mejores. Pero tampoco me convencen :PHola remoh,
siento decirte que aunque siga explicando los test en clase no me considero convencido. El día que salga algo que los substituya seré el primero en saltar del barco de los test.Ya que como comenté en el anterior post el esfuerzo es demasiado elevado , a diferencia (como tu bien has dicho) de otras tecnologías como pueda ser la integración continua.
Respecto a Selenium, quiero comentar hay una forma de hacer los Test para que no se rompan tan facilmente. Os comento mi caso:
Todos los widgets que uso en la aplicación se pueden manejar desde JavaScript mediante objetos de JavaScript. Así que en vez de ir directamente al HTML le digo al componente que "realice" la acción del usuario.
Por ejemplo cuando pinchas en un link que tiene forma de botón en vez de poner en selenium
selenium.click("Controls.Button.buttonAceptar.Middle.A");
que el test depende del id que le hayan dado al link (si tienes suerte en que hay id) se puede poner
selenium.runScript("window.buttonAceptar.onClick();");
Es decir llamar al propio widget desde JavaScript.
De esa forma es independiente el HTML que genere el propio widget y además no hay que conocer ese HTML enrevesado que genera.
Esto tiene dos problemas, primero que la librería debe estar preparada para que la automaticen desde JavaScript , pero al igual que en el código Java debemos programar pensando en el Test, en el HTML+JavaScript tambien deberíamos tenerlo en cuenta.El segundo problema es que realmente no estas probando el "click" del usuario sin llamando a un método "onClick" que pensamos que va a hacer lo mismo. En mi caso eso casi no es un problema pq el evento HTML llama al método javascript "onClick".
Saludos.
Pues entonces dejemoslo en que es un problema de forma y no de fondo, cada cual tendrá su interpretación de cual es la forma correcta y este es un mundo libre, así que dado que estamos de acuerdo en que triunfe el mensaje, discutamos sobre test que es mucho más divertido.
Ya que como comenté en el anterior post el esfuerzo es demasiado elevado , a diferencia (como tu bien has dicho) de otras tecnologías como pueda ser la integración continua.
Lo malo es que la IC sin test es como un jardin sin flores, sólo compruebas que todo compila (que menos da una piedra) pero es mucho mejor comprobar que todo funciona. ¿Para que sirve la IC a alguien que use ruby si no hace test?...
Y desde luego que el esfuerzo es elevado, porque el premio y la mejora también lo son, ni en el software ni en ninguna otra cosa se regalan duros a peseta, aunque yo os puedo asegurar que cuando te manejas con soltura en testing (y haces los test primero, y usas mocks cuando toca, y tienes un conjunto de herramientas que ya dominas) el esfuerzo se vuelve aceptable. Sobre todo si trabajas en equipo el tener la tranquilidad de que cada vez que te bajas algo del SCM esta todo no sólo compilando sino funcionando te hace ser incluso más productivo. ¿cuanto tiempo perdeis porque os bajais lo que hay en el SCM y como esta roto no podeis seguir trabajando en vuestra parte del proyecto?, nosotros antes perdiamos mucho tiempo con cosas así.
Sobre lo de selenium, justo estas dos ultimas semanas (despues del podcast jeje) he estado metiendome más a fondo en un proyecto con selenium, hemos utilizado un enfoque parecido al tuyo. Donde teniamos más problemas de fragilidad era a la hora de comprobar resultados, el tema este de "isTextPresent()" me parece algo cutrillo, ¿Y si quiero comprobar que muestro una tabla de resultados y además se muestran en cierto orden?
La idea ha sido tirar de "getEval" en conjunto con JQuery para simplificar aún más la cosa, por ejemplo comprobar que una tabla tiene X filas es algo así: "selenium.getEval("$("grid").jqgrid('numRows'))" (me medio invento la sintaxis que no me acuerdo exactamente jeje). De igual modo se puede conseguir facil hacer metodos para que nos devuelva la fila N etc,etc.
En general con JQuery es muy facil preguntar por elementos de la pagina haciendo uso de sus selectores que son muy potentes, y su usas componentes tipo tree, grids o demás tienes un API en js que te permite invocarlos desde selenium de forma que ya no dependes de la posición en la que estén en la pagina.
De todos modos los test de UI son con mucho los más dificiles de escribir.
Hola,
Aprovechando que nos hemos aclarado que estamos todos a favor de los tests y es cuestión de como animamos el equipo a ganar ;), una pregunta para los que llevan más kilometraje que yo en esto:
.- El sistema con el que trabajo actualmente tiene unas ~300-400 tablas
.- Del sistema yo muestro información, no se actualiza, y cada página muestra información que, a través de vistas, depende de varias tablas, las páginas más simples de unas 5-10 a las más complejas que necesitan 10-20 tablas.
.- Los datos que muestran son siempre parecidos (habras unas 20-30 páginas tipo) pero con una casuística extensa (si el flag este y este están así entonces muestra esto, si no aquello... etc.)
.- Se consultan además circunstancias externas (si tal fichero está disponible en S.O., si tal URL devuelve un 200).
Entonces, mi problema es que plantearse un sistema de tests para probar la casuística implica rellenar de algun modo la mayoría de los cientos de tablas y asegurarse de que pongo todos, o casi, los casos posibles, que son bastantes. Si en vez de rellenar la BDD pongo una capa intermedia, entonces no estoy probando la BDD, que es el 80% del sistema. Aparte de eso como la BDD se usa en muchos otros proyectos y sufre modificaciones, mantener la "copia para tests" actualizada requeriría un trabajo extra a veces complejo.
Ahora mismo los cambios los verifican los usuarios, que hay unas decenas, mirando cada una la parte que conoce y comprobando que los datos salen como tocan. Y claro, no es perfecto y alguno se cuela pero el coste es mínimo y de paso nos dan el visto bueno a la presentación, cosa que total tendríamos que hacer.
Por último, la aplicación en si es importante pero no es crítica en tiempo real. Es decir, se detecta un fallo, se soluciona y se arregla en unas horas o en un día y no se muere nadie ni el negocio se derrumba. Tampoco cuenta el sistema con un gran número de desarrolladores, ya quisiera, por lo que no hay graves problemas de integrar código de diferentes personas ni grandes merge etc.
Así que... ¿alguna idea de como montar un sistema de test en este tipo de entornos para que "salga rentable"? A mi fráncamente me gustaría montar algún sistema pero no encuentro una forma que realmente me compruebe el sistema real, y no una copia artificial, y que no me lleve demasiado trabajo por que entonces me dirán que por qué "pierdo el tiempo" en eso :(.
Buenas,
Por lo que comentas tienes un sistema de informes. En el caso de tu campo tiene una cosa buena (que no es crítico como un TPV, Sistema bancario, Venta Web) y otro malo que tratais con mucha lógica de tablas, conceptos, etc.
Aquí la dificultad no está en asegurar que el sistema funcione. Normalmente una vez que tienes el Select lo lanzas contra la plantilla y ya se imprime. La dificultad está en entender los conceptos y aplicar las formulas, filtros adecuados. Al tener 300-400 tablas, claramente la lógica es compleja.
Simplemente tu objetivo no es tener un sistema estable, si no que los cálculos sean correctos ya que va dirigido a personal de responsabilidad y de toma de decisiones.
Yo estube en proyectos parecidos, en el primer podcast comenté que una misma cosa la intentabamos calcular redudante entre diferentes formas, incluso entre diferentes personas, a modo de comprobante. Además, nosotros mismos nos creabamos nuestras pruebas de validacion por lo que si algo lo podiamos calcular de varias formas, las calculabamos para asegurarnos de que lo que presentabamos era fiable. Por ejemplo, si tienes facturas y tienes otra tabla recibos y ambas tienen un importe, si sumas las facturas que tienen recibos y sumas el importe de los recibos, el importe debe ser el mismo. Estoy seguro que con 300-400 habrá totales que los podreis calcular de varias formas ya que no creo que esté normalizado por optimización.
Se pueden hacer más cuentas que no tienen porque ser exactas si no comprobar que sean mayores o menores. Por ejemplo, no se puede tener menos tickets que productos vendidos, etc. Depende también de vuestra lógica de negocio.
En cuanto a test de unidad en informes, imagino que utilizareis una herramienta externa. (La herramienta externa claramente no creo que haya falta probarla).
Saludos, Jorge
Hola greeneyed:
Tienes un problema: establecer el estado inicial de los test es muy costoso (gran número de tablas + otros factores externos), con dbunit se reduce el esfuerzo pero sigue siendo bastante costoso, nadie te libra de escribir en un xml cada dato necesario para el test.
Tienes una ventaja: como no escribes puedes usar la base de datos real para tus test, no te vas a cargar nada metiendo datos de test en una bd de producción, además es muy posible que esa base de datos tenga datos antiguos que ya no se modifiquen y puedas usar como "estado conocido" para asegurar que tus test sean repetibles.
Un problema de este enfoque es que tengas muchos test que le den caña a la bd en horas en las que la producción también sea critica o con mucha carga, para esto estaría bien montar un entorno de IC y que los test se pasarán no en cada compilación sino a horas determinadas donde sabes que no que no hay nadie usando la aplicación, por la noche o cosas así. A determinada hora despliegas la app en un servidor de pruebas y le pasas los test con selenium o similar, con esto además tienes todos los días una versión de pruebas desplegadas con la ultima funcionalidad y incluso podrías pedir a los usuarios que prueben si tal o cual dato sale bien cualquier día porque siempre tienes una versión sobre un servidor de pruebas, así antes de pasar a producción sabes que la cosa esta como debe.
Yo optaría por usar la bd real en tu caso, al menos para probar funcionalidad existente, y haría test funcionales (con selenium, httpunit o similares), intentando seguir la regla del 80/20 si aplica en tu caso, vamos probar primero el 20% que se usa en el 80% de los casos. Una vez que este montado el entorno otra cosa que haria siempre es ante incidencias escribir un test primero que la reproduzca y luego solucionarla, de modo que te aseguras no tener regresiones de esas incidencias.
Lo bueno es que estos test requieren relativamente poco esfuerzo, te quitas la parte de establecer el estado previo conocido que es la más costosa, y añaden un buen nivel de seguridad de lo que realmente te importa, que al usuario le funcione.
Otro tema son las funcionalidades nuevas, no modificaciones sobre paginas existentes sino cuando te pidan cosas totalmente nuevas, ahí si que meteria pruebas unitarias con dobles de pruebas para todos los elementos externos y luego por supuesto también haria las pruebas funcionales. A mi las pruebas con dobles me sirven para avanzar en pequeños pasos y saber que cuando he terminado tal clase esta bien y no he metido la pata poniendo un if al reves o cualquier tonteria de estas que luego cuando te llega la incidencia de producción tienes que depurar y a veces tardas mucho en descubrir. Pero pruebas con dobles para funcionalidad existente puede ser muy complejo y requerir un rediseño que si la aplicación esta funcionando muy probablemente no merezca la pena.
Ya que estamos, cuando se trata de incluir test en proyectos ya existentes hay un libro fantastico de Michael Feathers sobre el tema Working effectively with legacy code
Hola,
No me expliqué del todo bien. No hay "cálculos" que hacer, es básicamente pintar resultados de queries entonces no hay otra forma de comprobar que sale lo que quieres más que comprobando eso... que sale lo que quieres. Por eso hacer los tests es "tan costoso" ya que han de ser explicitos por que no los puedes calcular por otro lado y comparar.
Y el objetivo en mi caso no es un sistema estable, que sí que lo es, si no mostrar correctamente la información en todas sus posibles combinaciones. Digo que la estabilidad del sistema no es tanto problema por que lo se hace es generar todas las páginas (~50K) cada día y el usuario accede al generado. Si un día por algo no se genera no pasa nada por que queda la generación del día anterior.
Y no es un sistema legacy, excepto la BDD que tampoco lo es en sí, si no que tiene sus añitos y su evolución y simplemente es complejo el sistema. El problema como bien mencionas, remoh, es establecer el estado inicial y luego mantenerlo, probando todas las combinaciones, o la mayoria para ese 80/20. Podría cojer y hacer un conjunto inicial de datos para tests, pero abarcar la funcionalidad que puede haber y sus combinaciones requeriría un trabajo bastante extenso, que luego habría que mantener para poder seguir el ritmo de las modificaciones que sufra la BDD original.
Y claro, "competir" con el sistema actual donde los tests "manuales" son 20 personas diferentes que cada una mira su parte y comprueban que todo funciona... es dificil.
Es decir, el propio sistema ya me dice si funciona, ya que los errores en la generación quedan reflejados, así que lo queda por testear es la interfaz de usuario, que es la parte más "chunga" y que más "facilmente" sustituye un humano, que con un vistazo detecta muchas cosas. Y la cuestión es que al fin y al cabo aunque lo monte, las 20 personas lo seguirán mirando igual, ya que a veces el problema está en la BDD y hay que corregirla, así que encima no puedo alegar que nos ahorraremos eso...
En fin, que creo intentaré meter los tests en otra aplicación un poco más "friendly". Mi problema es que mis aplicaciones son de un perfil muy así... poco cálculo y mucho meollo en la interfaz de como se muestran datos de la BDD. Ains.
Sinceramente, lo que hicieran personas hace años no se puede comparar lo que se hace ahora, por eso hace 30 años o 40 se podía ser profesional sin hacer tests, por que los tests automáticos quizá no se usaban o conocían o no había medios, pero se hacían otras pruebas. Pero hoy en día que en el desarrollo y facilidades que hay para hacer tests, si que considero que es muy necesario hacer tests para ser considerado profesional. Que haya genios a los que no les haga falta, no les convierte en profesionales, simplemente son genios y no les hace falta ser profesionales.
A los que no hagan tests, mejor les convendría dedicar el tiempo a aprender y menos a opinar si se es o no profesional por no usar tests. De todas maneras creo que cualquiera que usa tests ahora, antes de usarlos se creía un buen profesional pero seguramente ahora no volvería al punto en el que no los usaba.
Por supuesto a mi me queda mucho camino por recorrer en esto de los test automáticos.
Escribe tu comentario