Um SIM retumbante com TDD (e com algumas exceções)
Tudo bem controverso, mas eu diria que quem responde 'não' a essa pergunta está perdendo um conceito fundamental de TDD.
Para mim, a resposta é um retumbante sim se você seguir o TDD. Se você não é, então não é uma resposta plausível.
O DDD no TDD
O TDD é frequentemente citado como tendo os principais benefícios.
- Defesa
- Garantir que o código possa mudar, mas não seu comportamento .
- Isso permite a sempre tão importante prática de refatoração .
- Você ganha esse TDD ou não.
- desenhar
- Você especifica o que algo deve fazer, como deve se comportar antes de implementá- lo.
- Isso geralmente significa decisões de implementação mais informadas .
- Documentação
- O conjunto de testes deve servir como documentação de especificação (requisitos).
- O uso de testes para esse fim significa que a documentação e a implementação estão sempre em estado consistente - uma alteração em um significa uma alteração em outro. Compare com a manutenção de requisitos e design em um documento do Word separado.
Separe a responsabilidade da implementação
Como programadores, é terrivelmente tentador pensar nos atributos como algo de significância e getters e setter como uma espécie de sobrecarga.
Mas os atributos são um detalhe de implementação, enquanto setters e getters são a interface contratual que realmente faz os programas funcionarem.
É muito mais importante escrever que um objeto deve:
Permitir que seus clientes alterem seu estado
e
Permitir que seus clientes consultem seu estado
então como esse estado é realmente armazenado (para o qual um atributo é o mais comum, mas não o único).
Um teste como
(The Painter class) should store the provided colour
é importante para a parte da documentação do TDD.
O fato de a eventual implementação ser trivial (atributo) e não trazer benefícios de defesa deve ser desconhecido para você quando você escreve o teste.
A falta de engenharia de ida e volta ...
Um dos principais problemas no mundo do desenvolvimento de sistemas é a falta de engenharia de ida e volta 1 - o processo de desenvolvimento de um sistema é fragmentado em subprocessos desconexos cujos artefatos (documentação, código) geralmente são inconsistentes.
1 Brodie, Michael L. "John Mylopoulos: costurando sementes da modelagem conceitual". Modelagem Conceitual: Fundamentos e Aplicações. Springer Berlin Heidelberg, 2009. 1-9.
... e como o TDD resolve
É a parte da documentação do TDD que garante que as especificações do sistema e seu código sejam sempre consistentes.
Projete primeiro, implemente depois
No TDD, escrevemos primeiro o teste de aceitação com falha, e depois escrevemos o código que os deixou passar.
Dentro do BDD de nível superior, escrevemos os cenários primeiro e depois os fazemos passar.
Por que você deve excluir setters e getter?
Em teoria, é perfeitamente possível no TDD uma pessoa escrever o teste e outra implementar o código que o faz passar.
Então pergunte a si mesmo:
A pessoa que está escrevendo os testes para uma classe menciona getters e setter.
Como getters e setters são uma interface pública para uma classe, a resposta é obviamente sim , ou não haverá como definir ou consultar o estado de um objeto.
Obviamente, se você escrever o código primeiro, a resposta pode não ser tão clara.
Exceções
Existem algumas exceções óbvias a essa regra - funções que são detalhes claros da implementação e claramente não fazem parte do design do sistema.
Por exemplo, um método local 'B ()':
function A() {
// B() will be called here
function B() {
...
}
}
Ou a função privada square()aqui:
class Something {
private:
square() {...}
public:
addAndSquare() {...}
substractAndSquare() {...}
}
Ou qualquer outra função que não faça parte de uma publicinterface que precise de ortografia no design do componente do sistema.