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

79

Tenho ouvido falar do estilo londrino em relação ao estilo de Chicago (às vezes chamado de estilo Detroit) de Test Driven Development (TDD).

Workshop do Grupo de Usuários de Programação Extreme Utah:

Interaction-style TDD is also called mockist-style, or London-style after London's Extreme Tuesday club where it became popular. It is usually contrasted with Detroit-style or classic TDD which is more state-based.

Oficina de Jason Gorman :

The workshop covers both the Chicago school of TDD (state-based behaviour testing and triangulation), and the London school, which focuses more on interaction testing, mocking and end-to-end TDD, with particular emphasis on Responsibility-Driven Design and the Tell, Don't Ask approach to OO recently re-popularized by Steve Freeman's and Nat Pryce's excellent Growing Object-Oriented Software Guided By Tests book.

A postagem Clássico TDD ou "London School"? Jason Gorman foi útil, mas seus exemplos me confundiram, porque ele usa dois exemplos diferentes em vez de um exemplo com as duas abordagens. Quais são as diferenças? Quando você usa cada estilo?

    
por Arturo Herrero 06.12.2011 / 21:42
fonte

2 respostas

69

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.

    
por 06.12.2011 / 23:33
fonte
28

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.

    
por 06.12.2011 / 23:27
fonte

Tags