“TDD é sobre design, não verificação”; concretamente, o que isso significa?

4

Eu estive pensando sobre isso. O que exatamente queremos dizer com design e verificação?

Devo aplicar o TDD para garantir que meu código seja SOLID e não verificar se o comportamento externo está correto?

Devo usar o BDD para verificar se o comportamento está correto?

Onde eu fico confuso também em relação ao código TDD Katas, para mim eles pareciam mais sobre verificação do que sobre design; eles não deveriam ser chamados BDD Katas ao invés de TDD Katas?

Acredito que, por exemplo, o boliche Kata do Tio Bob conduz ao final de um projeto interno simples e agradável, mas senti que a maior parte do processo estava centrada mais na verificação do que no design. O design parecia ser um efeito colateral de testar o comportamento externo de forma incremental. Não senti tanto que estávamos concentrando a maior parte dos nossos esforços no design, mas mais na verificação. Enquanto normalmente nos dizem o contrário, que no TDD, a verificação é um efeito colateral, o design é o objetivo principal.

Então, minha pergunta é sobre o que devo focar exatamente, quando faço TDD: SOLID, usabilidade de API externa ou outra coisa?

E como posso fazer isso sem me concentrar na verificação?

Em que vocês concentram sua energia quando estão praticando TDD?

    
por foobarcode 06.10.2012 / 17:50
fonte

5 respostas

4

As katas do código TDD são sobre o aprendizado práticas do TDD e como elas impulsionam o design (e aprendem um bom design dessa forma - sim, normalmente isso significa aprender a escrever código SOLID).

Isso significa que o TDD trata de um bom design - mas é inútil ter um código bem projetado que não resolva um problema. É aí que a verificação entra - isso pode ser feito de várias formas, sendo o BDD um deles como uma das muitas técnicas de teste de aceitação automatizada.

A verificação é sobre como garantir que o código escrito esteja resolvendo o problema correto.

Então, ao fazer o TDD, concentre-se no design - verifique se ele está limpo e sólido.

Mas não se esqueça de adicionar testes de unidade e testes de aceitação (e quaisquer outros testes que sejam considerados necessários).

    
por 06.10.2012 / 18:00
fonte
8

Pode ser útil ver uma foto:

Observequeostestesdeaceitação(ouseja,verificação)estãoforadocicloTDDusual.Ostestesdeunidadegarantemqueseucódigofuncione,masostestesdeaceitaçãogarantemqueocódigoatendaaosrequisitosdocliente.

ATDDsignifica Desenvolvimento Orientado a Testes de Aceitação.

    
por 06.10.2012 / 18:17
fonte
1
Verificação é para garantir que um produto atenda a todos os requisitos conforme foram especificados. O Test Driven Development , por si só, não especifica a qualidade dos testes escritos e, como tal, não pode garantir que um produto está em total conformidade com a sua especificação. Quando você escreve seus testes primeiro, você tende a se concentrar na produção de softwares facilmente testáveis - você alcança uma grande quantidade de cobertura de código funcional , e tenha a oportunidade de pensar sobre como sua API deve ser, escrevendo seu teste antes de escrever a funcionalidade de backup.

Ao escrever seus testes, você também deve pensar em verificação - mapeie seus testes para suas necessidades, pense em outros caminhos de códigos dentro de suas funções (obtenção de uma declaração mais alta ou cobertura de decisão). Mas o TDD não diz nada sobre isso - apenas diz que você deve escrever seus testes primeiro e então escrever a quantidade mínima de código para fazer os testes passarem. Sem garantir pelo menos uma cobertura completa dos requisitos dos seus testes e uma cobertura maior do caminho, seus testes podem não ser adequados para fins de verificação.

    
por 06.10.2012 / 17:58
fonte
1
> tdd is about design not verification.

Eu traduziria isso para "o benefício do tdd é um bom design" .

No tdd, você se concentra em escrever o código de verificação.

Ao fazer tdd (= escrever testes isoladamente antes de implementar o código), você obtém um bom design (= acoplamento mínimo) automaticamente como efeito colateral.

Oposto a escrever testes automatizados após a implementação do código, você também obtém a verificação, mas sem o benefício extra de design.

    
por 07.10.2012 / 09:23
fonte
1

É realmente sobre ambos, mas a verificação é um bom efeito colateral que pode ser obtido escrevendo os testes após o código. O benefício real do TDD e de escrever o teste primeiro é que ele ajuda a consolidar o design refinando o design de cada unidade lógica ou regra de negócios e construindo o restante das unidades lógicas sem quebrar as outras unidades do design e mantê-las de se tornar excessivamente acoplado.

Por exemplo, alguns desenvolvedores usam a abordagem TDD quase como um "quadro branco", onde os testes e o código residem no mesmo arquivo inicialmente. Dá muita liberdade para evoluir a lógica com os testes, bem como testar ideias. Então, à medida que o design evolui, o código é extraído do módulo de teste para o próprio aplicativo.

Os testes resultantes podem ser usados para verificação conforme mais refatoração é feita.

    
por 07.10.2012 / 15:20
fonte