TDD no sirve para todo pero ayuda

Soy un fiel defensor de hacer tests y sobre todo de hacerlos antes de escribir una linea de código, pero no todo lo que hacemos tiene que estar hecho con TDD. Quizás el título sea un poco clickbait,.. en este post me gustaría que reflexionásemos sobre algunos aspectos a tener en cuenta de por qué Test Driven Development no es una bala de plata aunque ayuda mucho al diseño y de algunos temas interesantes alrededor del testing, refactoring y software.

"Cuando la única herramienta que tienes es un martillo, todo problema comienza a parecerse a un clavo".

No todo lo que hacemos tiene que estar hecho con TDD. ¡Pensar antes de escribir es mucho más importante! Por esta razón, estamos seguro de que es posible hacer buen software sin TDD. Aunque creo que hacer software sin TDD es más complicado porque no todo el mundo es capaz de pensar antes de escribir. Además a veces las “circunstancias” nos empujan a ir rápido, a tenerlo listo ya, o incluso a pensar (ilusos de nosotros) esto lo arreglamos más adelante. Del mismo modo, podemos llegar a un lugar oscuro si no nos planteamos a probar el software lo más pronto posible. Seguro que alguna vez nos ha pasado que llegamos a un una clase, servicio o feature que es difícil de probar. ¡eso sin duda es un “mal olor”! Quizás en el futuro ese mal olor acabe en algo podrido que y nos dé algún que otro dolor de cabeza. En cualquier caso cuando usamos TDD este nos provee de un proceso para analizar los problemas, para comprender qué es lo que está pasando, qué casos se nos pueden presentar, qué casos son excepcionales,….. además nos proporciona un arnés de seguridad para ir mejorando(refactor). Sin este proceso de TDD: hacer un test, comprobar que falla, hacer código para pasar el test y refactorizar, Lo qué tenemos es un proceso custom, donde cada miembro del equipo crea de manera distinta y por quizás lleguemos a situaciones en las que modificar un código se nos haga un poco cuesta arriba.

Continúa leyendo “TDD no sirve para todo pero ayuda”

Buenas prácticas de desarrollo en Etsy Parte 3

Esta es la tercera parte de la traducción del manual de buenas prácticas de Testing en Etsy donde se aborda el tema del Legacy Code.

Legacy code

La mayoría del código fuente que ha sobrevivido normalmente no fué escrito con un diseño limpio o pensando en la usabilidad/reutilización. Puede tener estado global, o no tener ninguna abstracción ( de modo que, por ejemplo, todas las operaciones de base están en una clase o en un método aislado que no está relacionado con la base de datos).

Vamos a tener que utilizar la imaginación cuando nos encontramos con código como este. Al final, nuestro trabajo está por hacer, tenemos que diseñar el código de acuerdo a unas normas, independientemente de como interactue ahora.

Continúa leyendo “Buenas prácticas de desarrollo en Etsy Parte 3”

Buenas prácticas de testing en Etsy Parte 1

Este artículo es un un conjunto de buenas prácticas para testing utilizadas en Etsy. Es la primera parte de una traducción de este documento sobre buenas prácticas de testing.

¿Qué es este documento?

Esto es una introducción a las ideas y aproximaciones que motivan el buen testing. Tomaremos un ejemplo de un sistema escrito en PHP y testeado con PHPUnit y discutiremos como testear un buen diseño y como diseñar teniendo en mente la testesabilidad.

etsy logo

Audiencia y prerrequesitos

Este documento está pensado para cualquier ingeniero de Etsy.

Continúa leyendo “Buenas prácticas de testing en Etsy Parte 1”

la jerga del testing

Hace ya unos cuantos post que estoy hablando sobre testing, PHPUnit, TDD y demás. Llegados a este punto tengo nos cuantos conceptos en la cabeza y no quiero que se me olviden así que he decidido escribirlos todos en un post.

Tiempo atrás escribí otro post sobre la jerga de los informáticos, así que ahora creo que es el momento de escribir “LA JERGA DEL TESTING”

Así que vamos a por ello:

Setup / Test / Assert / tear down

Toda prueba automática se compone de 4 partes:

  • Setup: Todo lo que se necesita antes de ejecutar la prueba.
  • Test: Es el código que queremos probar.
  • Assert: Es la parte donde comparamos el resultado del código con alguna condición esperada.
  • Teardown: Limpiamos todo lo que hallamos utilizado durante la prueba para dejar el software que estamos probando en un estado estable,tal y como estaba antes del setup.

Continúa leyendo “la jerga del testing”