Micropost: Testing shows the presence of bugs

16 enero 2009 By In Programacion

Una cosa que se suele hacer bastante en javascript es resetear un formulario, es decir, devolver el formulario a su valor inicial.

Con jquery esto es bastante fácil:



$(

					
							
					
Trackback URL

					
					
, ,
  1. PoKuTe
    16/01/2009 at 2:52 am Permalink

    ahi mi dilema a la hora de hacer estimaciones, cuanto dedicar a testeo. hay cosas sencillas con pocos flujos de trabajo, pero una migracion de base de datos o un upgrade del lenguaje, supone que deberias de testearlo todo! y en las aplicaciones en las que suelo trabajar…. habria que contratar a un tercio de china para hacerlo en tiempo razonable xD

  2. Pau Sanchez
    16/01/2009 at 10:03 am Permalink

    Testeo y «tiempo razonable» no se suelen llevar bien xD

    Normalmente cuanto más tiempo, más tests y mejor covertura de todo.

    Yo la verdad es que la regla que suelo aplicar es que si algo es crítico o que va a ser usado por otros módulos, entonces debe tener unit tests sí o sí.

    En cualquier caso, mirgrar una base de datos es otra de esas cosas, que aunque se vaya a hacer una vez, sí debe testearse bien. Pero lo más importante en este caso, es guardarse la base de datos original, no vaya a ser que luego falte algo por migrar 😉

  3. CaDs
    19/01/2009 at 12:04 pm Permalink

    Yo he estado usando TDD durante el último año y si bien he de decir que desarrollar tu código en base a test es una gran técnica y robustece enormemente el código, sigue siendo necesario disponer de un buen tester en el equipo.
    El problema es que desarrollando a partir de test nos centramos inconscientemente en cómo deben funcionar las cosas, y por tanto en muchas ocasiones dejamos de escribir test para determinados escenarios (que a la larga son los que fallan)
    En fin, no me enrollo.
    Genial el blog!

  4. Pau Sanchez
    20/01/2009 at 5:24 am Permalink

    CaDs: totalmente de acuerdo. No sólo es que uno se centre en los tests prácticos, es que yo creo que debe hacerlo. Uno no puede pretender hacer tests de caja blanca, porque el desarollo duraría una eternidad, claro está, si no está desarrollando un sistema crítico para lanzar misiles, manejar plantas nucleares, etc…. entonces cualquier test es bienvenido 🙂

    Mi opinión (al menos es lo que yo hago) es que hay que ir haciendo tests para probar las cosas conforme se desarrolle (por pequeño que sea el test que se haga, es preferible tener 1 test que testea el 2% de la funcionalidad, que no tener ninguno; además se queda todo preparado para seguir añadiendo tests, que eso siempre da pereza).

    Una vez el producto tiene ya sus tests, cuando se prueba manualmente y se encuentra un bug (o bien por uno mismo, o por un usuario), mi punto de vista es que hay que añadir un test-case que lo reproduzca y finalmente solucionarlo y verificarlo no sólo en el test que se acaba de hacer, si no en el sitio donde originariamene apareció el bug.

  5. Fer Martin
    22/01/2009 at 11:38 pm Permalink

    http://www.youtube.com/watch?v=6LdsIVvxISU

    y…. viva Dijkstra!!!! Pero el gran Oluwaseun Akinmade tampoco se queda atras ehh!! 🙂

  6. Fer Martin
    22/01/2009 at 11:39 pm Permalink

    http://www.youtube.com/watch?v=6LdsIVvxISU

    y el gran Oluwaseun Akinmade tambien nos da su opinion al respecto!

    Un abrazo,
    Fer

  7. Pau Sanchez
    27/01/2009 at 2:53 pm Permalink

    Gracias por el enlace.
    La verdad que el video tiene muy buena pinta. A ver si saco un rato estos días y le echo un vistazo.

    Por cierto, eso de poner el enlace del video al principio del comentario se ve que no le ha gustado a Askimet, ha bloqueado ambos comentarios.

    Un saludo!

  8. Gonzalo
    04/02/2009 at 8:20 am Permalink

    Si habeis trabajado con desarrollo en base a tests no entiendo el comentario de que porque se llevan mal con el tiempo, la verdad.

    Los tests ahorran muuuucho tiempo, tanto en la fase de depuración y estabilización de un proyecto como a la hora de añadir funcionalidad.

    Y otro punto que los hacen críticos, los tests unitarios salvan proyectos que sin ellos estarían abocados al fracaso.

    Haz tests hasta para cuando tires un par de líneas de javascript.

    Saludos,
    Gonzalo

  9. Pau Sanchez
    05/02/2009 at 12:17 pm Permalink

    Hola Gonzalo,

    He escrito un post con el objetivo de aclarar un poco eso de testeo vs tiempo razonable:
    Testeo y tiempo razonable no se llevan bien ¿o si?

    Un saludo!

Trackbacks

  1. Testeo y tiempo razonable no se llevan bien ¿o si? » Codigo Manso 05/02/2009 at 12:14 pm

    [...] que el artículo de Testing shows the presence of bugs ha generado unos cuantos [...]