Thursday, October 25, 2012

Resumen Clean Coders capitulo 6: TDD Parte 2 (II)



Continuamos con el resumen del Capitulo 6 Parte 2. Tal y como comentamos el capitulo es muy completo y contiene gran cantidad de información por lo que hemos dividido el resumen en tres posts. Este es el segundo.

Si no lo has leido, puedes comenzar por el anterior post sobre este capitulo.

Para trabajar con código legacy en el que no tenemos tests:

  • Encuentra un modulo pequeño que puedas probarlo sin realizar demasiados cambios
  • Realiza los tests para realizar esos cambios con más seguridad
  • Para funcionalidades nuevas, se hacen pequeños cambios para poderlas testear
  • Si en una modificación, existe la posibilidad de modificar y hacer los tests a posteriori o hacer un nuevo módulo, deberemos hacer un nuevo módulo, usando TDD Siempre que sea código nuevo, se hace con TDD

Como testear GUI/View

  • Para la parte de vista pura, no merece la pena, puesto que es una parte que se presta a muchos cambios (estilo, presentación, …) y que además no tiene un resultado prefijado sino que se suele ajustar continuamente
  • Pero se puede probar todo el código relacionado en las capas anteriores...
  • Es decir podemos probar el contenido de los elementos de pantalla, pero no merece la pena testar cómo están posicionados, qué forma tienen, colores, etc...
  • Para ello se separa el GUI en dos componentes Presenter / View
    • Presenter interroga objetos de negocio y prepara estructuras de datos
    • Las estructuras de datos generadas por el Presenter, son renderizadas por el objeto View
    • Se testea el Presenter
  • Algunos hacen tests para las vistas (a nivel de interface), pero en ese caso lo hacen después de realizar las vistas, con el objetivo de que una vez que han conseguido un resultado, detectar si cambia. El, en general no lo recomienda.

Como testear la BD

  • Se testea que tu esquema y tus consultas funcionan como se supone
  • Necesitas tener la aplicación y la capa de BD separada
  • Esto permite probar la aplicación sin la BD real
  • Luego se puede probar la capa de BD separada. Por ejemplo se puede testear:
    • Se puede testear que se genera el SQL correcto
    • Incluso se puede probar que el SQL se comporta bien cargando una pequeña cantidad de datos

Disciplina y profesionalismo

  • El software es una disciplina que tiene que atender a muchísimos detalles, cualquier pequeño cambio y/o error hace que la aplicación deje de funcionar. Es muy propenso al fallo humano y las consecuencias (a nivel de la aplicación) suelen ser importantes.
  • Esto no pasa en otras disciplinas, y quizás en la que si pasa es en contabilidad y por eso establecieron como “buena práctica” el “sistema de partida doble” (Double-entry bookkeeping system) por el que cada entrada se realiza de dos formas independientes con cálculos independientes de forma que si existe una discrepancia se detectase de forma más o menos inmediata.
  • El TDD sería el equivalente en desarrollo de software a esta buena práctica del “sistema de partida doble” puesto que todo se desarrolla con un doble flujo (el de test y el de producción) que se validan el uno al otro.
  • Como desarrolladores profesionales debemos esperar conseguir que el departamento de QA no encuentre errores en nuestras entregas y en caso de que los encuentre debemos esforzarnos en que no pueda volver a pasar ese tipo de error.
  • Debemos liberar código que sabemos que funciona (lo contrario es irresponsable y no profesional).
  • La mejor forma conocida para asegurarnos de que el código que liberamos funciona es seguir la disciplina del TDD en su creación.
  • Debemos buscar tener una cobertura de código del 100%, ese es el objetivo, aunque puede que en algún caso no sea totalmente posible, pero el 100% debe ser lo que se persiga.

En el próximo post terminaremos con las conclusiones de este capitulo...

No comments: