¿Qué son las escuelas TDD de Londres y Chicago?

Suponga que tiene una clase llamada "libro mayor", un método llamado "calcular" que usa una "Calculadora" para realizar diferentes tipos de cálculos según los argumentos pasados a "calcular", por ejemplo "multiplicar (x, y)" o "restar (x, y)".

Ahora, suponga que desea probar lo que sucede cuando llama a ledger.calculate ("5 * 7").

La escuela London / Interaction le haría afirmar si se llamó a Calculator.multiply (5,7). Los diversos marcos de simulacros son útiles para esto, y puede ser muy útil si, por ejemplo, no posee el objeto "Calculadora" (suponga que es un componente o servicio externo que no puede probar directamente, pero sí lo hace. sabe que tiene que llamar de una manera particular).

La escuela de Chicago / State le haría afirmar si el resultado es 35. Los marcos jUnit / nUnit están generalmente orientados a hacer esto.

Ambos son pruebas válidas e importantes.

El artículo Mocks no son talones , de Martin Fowler es una buena introducción al tema.

Según el estilo de diseño que elija (y los principios de diseño sobre los cuales construye sus programas), hay al menos dos formas de ver un objeto:

1. Como una unidad que realiza cálculos basados en entradas. Como resultado de este cálculo, el objeto puede devolver un valor o cambiar su estado.
2. Como un elemento activo que se comunica con otros elementos en el sistema mediante el paso de mensajes.

En el primer caso, está interesado en lo que sale del procesamiento o en qué estado queda el objeto después de ese procesamiento. Aquí es donde los métodos como assertEquals() entran en la imagen. En este caso, no importa mucho qué otros objetos estuvieran involucrados en el procesamiento, qué métodos se llamaron, etc. Este tipo de verificación se denomina verificación basada en estado y es el estilo "clásico".

En el segundo caso, como la mayoría de los objetos ni siquiera devuelven ningún resultado (por ejemplo, los métodos void en Java), le interesa más cómo se comunican los objetos entre sí y si pasan los mensajes correctos en las circunstancias impuestas por la prueba Estas interacciones generalmente se verifican con la ayuda de marcos simulados. Este tipo de verificación se llama verificación basada en el comportamiento o en la interacción. Una de sus implicaciones es la técnica llamada Behavior Driven Development, mediante la cual desarrollas una clase asumiendo que sus colaboradores ya existen (incluso aunque todavía no existan), por lo que puedes codificar contra sus interfaces.

Tenga en cuenta que esta no es una opción ni / ni otra. Puede tener un estilo de diseño que combine ambos enfoques para obtener lo mejor de cada uno.