Guía para el código testeable

Siguiendo con los posts "de referencia", hoy traduzco un resumen de la Guía para el Código Testeable utilizada en Google y publicada en el blog de Miško Hevery. Esta guía consiste en 4 fallas de diseño a evitar, y las señales de advertencia que indicarían que las cometimos. Como siempre, se trata de reglas generales, no para seguirlas dogmáticamente, sino para tenerlas presente y considerar el costo de ignorarlas.

Quizás más adelante me ponga a traducir la cosa más a fondo, porque se explica todo con mayor detalle, con argumentos y ejemplos. Mientras tanto, quienes puedan leer inglés, háganse un favor y vayan a la fuente.

Falla #1: El constructor hace trabajo
Señales de advertencia:

• Se usa el operador new en el constructor o en la declaración de campos
  
• Llamadas a métodos static en el constructor o en la declaración de campos
  
• Cualquier cosa en un constructor más allá de asignación de campos
  
• Objetos que no queden completamente inicializados una vez terminado el constructor (atención con los métodos initialize)
  
• Flujo de control (lógica condicional o cíclica) en un constructor
  
• Se construye un complejo grafo de objetos dentro de un constructor, en lugar de usar una factory o un builder
  
• Bloques de inicialización
  

Falla #2: Hurgar en los colaboradores
Señales de advertencia:

• Se pasan objetos pero nunca son utilizados directamente (sólo para obtener acceso a otros objetos)
  
• Violación de la ley de Demeter: la cadena de llamadas a métodos recorre un grafo de objetos con más de un punto (.)
  
• Nombres sospechosos: context, environment, principal, container, o manager
  

Falla #3: Estado global riesgoso y Singletons
Señales de advertencia:

• Uso de singletons
  
• Uso de campos static o métodos static
  
• Uso de bloques de inicialización static
  
• Uso de registries
  
• Uso de service locators
  

Falla #4: La clase hace demasiado
Señales de advertencia:

• Al describir lo que la clase hace usamos la palabra "y"
  
• Sería complicado para un nuevo programador leer la clase y rápidamente comprenderla
  
• La clase tiene campos que son usados solamente en algunos métodos
  
• La clase tiene métodos static que solamente operan sobre los parámetros
  

Miško responde a los lectores que dejan sus comentarios, acá va una muestra interesante:

En la falla #3 mencionás que el "uso de registries" es una señal de advertencia. Pero la mayoría de las aplicaciones tienen algunos objetos que necesitan ser accedidos desde todas partes, o al menos en base a algún contexto. ¿Cómo manejaríamos tales objetos sin un registry? (...)

Y la respuesta:

(...) Registry, Context, ServiceLocator, o como quieras llamarlo, es un problema. En primer lugar, ¿cómo obtenés su referencia? ¿Variable global?

Las variables globales son problemáticas:
http://misko.hevery.com/2008/08/25/root-cause-of-singletons/
http://misko.hevery.com/2008/08/17/singletons-are-pathological-liars/

Los locators son problemáticos:
http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/

Y la solución es Inyección de Dependencias aun si es un objeto ampliamente necesitado:
http://misko.hevery.com/2008/10/21/dependency-injection-myth-reference-passing/
(...)