Um ressonante SIM com TDD (e com algumas exceções)
Controversa, tudo bem, mas eu diria que qualquer um que responda '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 for, então não, é uma resposta plausível.
O DDD em TDD
O TDD é frequentemente citado como tendo os principais benefícios.
-
Defesa
- Garantir que o código pode mudar , mas não é o seu comportamento .
- Isso permite a prática sempre importante da refatoração .
- Você ganha este TDD ou não.
-
Design
- Você especifica o que algo deve fazer, como deve se comportar antes de implementá-lo
.
- Isso geralmente significa decisões de implementação mais fundamentadas .
Documentação
- O conjunto de testes deve servir como documentação 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 para um significa uma alteração para outro. Compare com a manutenção de requisitos e design em documentos separados do Word.
Separe a responsabilidade da implementação
Como programadores, é terrivelmente tentador pensar em atributos como algo significativo e como um tipo de sobrecarga.
Mas 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 soletrar que um objeto deveria:
Allow its clients to change its state
e
Allow its clients to query its state
em seguida, 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 documentação do TDD.
O fato de que a eventual implementação é trivial (atributo) e não traz nenhum benefício defense 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 os artefatos dos quais (documentação, código) são frequentemente inconsistentes.
1 Brodie, Michael L. "John Mylopoulos: costura sementes de modelagem conceitual." Modelagem Conceitual: Fundamentos e Aplicações. Springer Berlin Heidelberg, 2009. 1-9.
... e como o TDD resolve isso
É a parte 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 falho, depois escrevemos o código que os permite passar.
Dentro do BDD de nível superior, escrevemos os cenários primeiro, depois os fazemos passar.
Por que você deve excluir setters e getter?
Em teoria, é perfeitamente possível dentro de TDD para uma pessoa escrever o teste, e outra para implementar o código que a faz passar.
Então pergunte a si mesmo:
Should the person writing the tests for a class mention getters and setter.
Como os getters e setters são uma interface pública para uma classe, a resposta é obviamente yes , ou não haverá maneira de 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 esta regra - funções que são detalhes de implementação de clearcut e claramente não fazem parte do design do sistema.
Por exemplo, o 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 interface public que precise de ortografia no design do componente do sistema.