Diferença entre teste de unidade e desenvolvimento orientado a teste

64

Ao ler as descrições, entendo que nos testes TDD são feitos antes de escrever a função e nos testes unitários, são feitos posteriormente.

Essa é a principal diferença, ou os dois termos nem sequer podem ser comparados como tal. Talvez o Teste de Unidade seja uma parte integrada do TDD.

unit-testing tdd difference

— Shamim Hafiz
fonte

104

Teste de unidade refere-se ao que você está testando, ao TDD quando está testando.

Os dois são ortogonais.

Teste de Unidade significa, bem, testar unidades individuais de comportamento. Uma unidade individual de comportamento é a menor unidade possível de comportamento que pode ser testada individualmente isoladamente. (Eu sei que essas duas definições são circulares, mas parecem funcionar muito bem na prática.)

Você pode escrever testes de unidade antes de escrever seu código, depois de escrever ou enquanto escreve.

TDD significa (novamente, meio óbvio) permitir que seus testes conduzam seu desenvolvimento (e seu design). Você pode fazer isso com testes de unidade, testes funcionais e testes de aceitação. Geralmente, você usa os três.

A parte mais importante de TDD é o meio D . Você deixa os testes te guiarem . Os testes informam o que fazer, o que fazer a seguir, quando terminar. Eles dizem qual é a API, qual é o design. (Isso é importante: o TDD não se trata de escrever testes primeiro. Existem muitos projetos que escrevem testes primeiro, mas não praticam TDD. Escrever testes primeiro é simplesmente um pré-requisito para permitir que os testes conduzam o desenvolvimento.)

— Jörg W Mittag
fonte

1

Ótima resposta. gostaria de acrescentar ... TDD é quando você deixa testes para empurrá-lo e recursos para puxar seus esforços de desenvolvimento ...

— Martin

Eles não são ortogonais. Você não pode ter TDD sem testes de unidade.

— JacquesB

1

@JacquesB, por quê? Nossos testes não são o que você chamaria de testes de unidade por qualquer definição, eles dependem muito da infraestrutura e de outros componentes, mas ainda temos observabilidade suficiente para que nós - pelo menos alguns de nós - estejam fazendo TDD.

— AProgrammer

3

@AndrewWillems: TDD significa que os testes conduzem o desenvolvimento . Você não decide como será o design, dizem os testes. Você não decide no que trabalhar a seguir, dizem os testes. Você não decide quando termina, os testes dizem. É perfeitamente possível escrever testes primeiro e depois ignorar tudo o que eles estão dizendo. Por exemplo, você pode escrever os testes primeiro, mas continuar escrevendo o código mesmo depois que todos os testes estiverem verdes. Então, em outras palavras: você escreve testes primeiro, mas os trata apenas como testes e não deixa que eles conduzam o desenvolvimento.

— Jörg W Mittag

1

@ JörgWMittag Você pode estar certo de uma maneira purista, mas também sabe que o TDD não é preto e branco. Qualquer uso sensato do TDD não deixaria os testes conduzirem o desenvolvimento completamente, e os testes nem sempre decidem como será o design (talvez os testes de unidade possam parcialmente fazer isso, mas não os testes em um nível de abstração mais alto). E a refatoração? Qual é um aspecto muito importante do TDD. Também no mundo real não existe algo como 'ignorar tudo o que o teste está lhe dizendo'. Por definição, se você escrever testes primeiro, usa 'alguma forma de TDD'.

— Nickl

21

O teste de unidade é um componente do desenvolvimento orientado a testes

Você pode fazer testes de unidade sem fazer um desenvolvimento orientado a testes. No entanto, você não pode fazer o desenvolvimento orientado a testes sem usar testes de unidade.

Quando você faz o teste de unidade tradicional , você escreve o teste depois de escrever seu código.

A abordagem de desenvolvimento orientada a testes é escrever um teste de unidade antes de escrever um código.

As vantagens mais interessantes do TDD (IMHO) em comparação com o simples teste de unidade:

Código é código totalmente testado antecipadamente. É um teste indolor.
Obriga você a projetar suas classes corretamente.
Também obriga a mantê-lo simples e estúpido .
O ciclo do Refator Vermelho-Verde é o assassino absoluto da procrastinação!

Você perdeu a "unidade" de propósito na declaração: "No entanto, você não pode fazer o desenvolvimento orientado a testes sem usar o teste". ?

— ratkok

@ratkok: não, não foi de propósito. Deixe-me consertar isso.

Eu gosto mais dessa definição. É melhor reunir palavras do que outras respostas.

— Tek

2

Pode-se argumentar que você pode fazer TDD usando testes de módulo ou de sistema, em vez de testes de unidade verdadeiros. Eu não aconselho, pois você perde muito do benefício se os testes demorarem muito para serem executados, mas não é impossível.

— Toby Speight

13

TDD e teste de unidade são dois termos muito específicos que geralmente são mal utilizados.

O TDD está escrevendo um teste que falhará, depois escrevendo a quantidade mínima de código necessária para executá-lo e refatorando o código para torná-lo limpo. Isso é feito em ciclos, reprovado -> aprovado -> refatorado, adicionando um novo teste para cada requisito conhecido do código. Mais recentemente, o TDD tornou-se ainda mais especificamente sobre a gravação de testes de unidade nesse ciclo, para distingui-lo do ATDD (um subconjunto do BDD), que está gravando testes de aceitação em um ciclo semelhante.

Teste de unidade é sobre testar um código em unidades pequenas e isoladas. A confusão comum aqui é pensar que, se você estiver usando uma ferramenta de teste de unidade, como xUnit ou Rspec, para executar testes que você está escrevendo testes de unidade. Isto não é necessariamente verdade. Essas ferramentas podem ser usadas para executar, digamos, testes usando a estrutura Selenium - nesse caso, você está escrevendo testes de aceitação usando um executor de teste de unidade. Os testes de unidade são testes muito específicos, focados em um pequeno pedaço de lógica, isolado de todo o resto por questões de velocidade (para que você possa executá-los frequentemente e obter feedback rápido sobre novos bugs).

— pdr
fonte

1

Os testes JUnit para o próprio JUnit são um bom exemplo: uma parte significativa deles são testes funcionais e testes de aceitação, não testes de unidade, mesmo que estejam escritos em JUnit. Além disso, o criador do JUnit também é o criador do TDD, e o JUnit foi desenvolvido usando o TDD usando uma quantidade significativa de testes funcionais e de aceitação. O teste de aceitação é parte integrante do TDD.

— Jörg W Mittag

6

TDD é a abordagem de escrever os casos de teste antes do desenvolvimento, como você disse e, em seguida, o desenvolvedor grava o código para passar nos casos de teste. Teste de unidade é um termo usado para descrever um tipo de teste de escopo restrito que não seja o teste do sistema, teste de integração e teste de aceitação.

— M.Sameer
fonte

3

TDD é uma abordagem filosófica para escrever código: escreva os testes primeiro. Os testes que você escreve são testes de unidade.

— Tangurena
fonte

1

A maneira como separo os dois é considerar que o TDD tem menos a ver com testes e mais com o design do código. Os testes de unidade são então usados para definir as expectativas para o código final. Quando o código final é gravado e passa nos testes (especificações), você possui um código que foi projetado usando testes.

— Grant Palin
fonte

1

Todas excelentes respostas. Eu acrescentaria apenas que o teste de unidade tende a considerar a 'unidade' como um pequeno componente, enquanto o TDD se amplia para incluir testes de integração e aceitação.

(Algumas variantes do TDD consideram a 'unidade' como o menor passo incremental em direção à funcionalidade desejada ...)

— Steven A. Lowe
fonte

eles deveriam, mas na minha experiência na realidade eles não. As empresas / grupos dizem que fazem TDD, quando tudo o que fazem é forçar os programadores a testarem primeiro com os testes jUnit e depois usar o fato de que tudo já foi testado durante o desenvolvimento para eliminar (ou reduzir bastante) o controle de qualidade e os testes de integração.

— jwenting

1

A @jwenting não culpa a metodologia pelas deficiências daqueles que pretendem praticá-la. qualquer ferramenta pode ser mal utilizado

— Steven A. Lowe

1

Não, mas você deve perceber que há uma grande diferença entre o que o TDD é na teoria e o que é na realidade. E como a maioria das pessoas (incluindo o OP) provavelmente só vê a realidade, a diferença deve ser apontada para elas.

— jwenting

Considerando que o TDD é sobre design - por que incluiria testes de aceitação? como isso "conduziria" o design?

— Vitalii Isaenko

Os testes de aceitação @VitaliiIsaenko fornecem o escopo de mais alto nível para projetos

— Steven A. Lowe