Quais são as escolas de Londres e Chicago de TDD?

Suponha que você tenha classe chamada "razão", um método chamado "calcular" que usa uma "Calculadora" para fazer diferentes tipos de cálculos dependendo dos argumentos passados para "calcular", por exemplo "multiplicar (x, y)" ou "subtrair (x, y)".

Agora, suponha que você queira testar o que acontece quando você chama ledger.calculate ("5 * 7").

A escola London / Interaction gostaria que você afirmasse se o Calculator.multiply (5,7) foi chamado. Os vários frameworks de mocking são úteis para isso, e pode ser muito útil se, por exemplo, você não tiver propriedade do objeto "Calculator" (suponha que seja um componente externo ou serviço que você não pode testar diretamente, mas você sei que você tem que chamar de uma maneira particular).

A escola de Chicago / Estado gostaria que você afirmasse se o resultado é 35. Os frameworks jUnit / nUnit são geralmente voltados para isso.

Ambos são testes válidos e importantes.

O artigo Mocks não são Stubs , de Martin Fowler é uma boa introdução ao tópico.

Dependendo do estilo de design escolhido (e dos princípios de design sobre os quais você cria seus programas), há pelo menos duas maneiras de ver um objeto:

1. Como uma unidade que realiza cálculos com base em entradas. Como resultado dessa computação, o objeto pode retornar um valor ou alterar seu estado.
2. Como um elemento ativo que se comunica com outros elementos no sistema pela passagem de mensagens.

No primeiro caso, você está interessado no que sai do processamento ou em qual estado o objeto é deixado após o processamento. É aqui que métodos como assertEquals() entram na imagem. Nesse caso, não importa muito o que outros objetos estavam envolvidos no processamento, quais métodos foram chamados, etc. Esse tipo de verificação é chamado de verificação baseada em estado e é o estilo "clássico".

No segundo caso, como a maioria dos objetos nem retorna nenhum resultado (por exemplo, void methods em Java), você está mais interessado em saber como os objetos se comunicam entre si e se eles transmitem as mensagens certas sob as circunstâncias impostas pelo teste. Essas interações geralmente são verificadas com o auxílio de estruturas simuladas. Esse tipo de verificação é chamado de verificação baseada em comportamento ou baseada em interação. Uma de suas implicações é a técnica chamada Behavior Driven Development, pela qual você desenvolve uma classe supondo que seus colaboradores já existam (mesmo que eles ainda não existam), então você pode codificar em suas interfaces.

Observe que isso não é uma opção de escolha. Você pode ter um estilo de design que combine as duas abordagens para obter o melhor de cada uma delas.