Por que os testes funcionais não é suficiente? O que fazer testes de unidade oferta?

Question

Eu apenas tive uma conversa com o meu principal desenvolvedor que não concordavam que os testes de unidade são tudo o que necessário ou importante. No seu ponto de vista, os testes funcionais com uma cobertura de código suficiente elevada deve ser suficiente uma vez que quaisquer refatorações interiores (alterações de interface, etc.) não conduzirá aos ensaios sendo necessário para ser reescrito ou parecia novamente.

Eu tentei explicar, mas não foi muito longe, e pensei que vocês poderiam fazer melhor. ;-) Então ...

Quais são algumas boas razões para código de teste de unidade que testes funcionais não oferecem? Que perigos estão lá, se tudo que você tem são testes funcionais?

Editar # 1 Obrigado por todas as grandes respostas. Eu queria acrescentar que por testes funcionais eu faço apenas testes não significa em todo o produto, mas também testa os módulos dentro do produto, não apenas sobre o baixo nível de um teste de unidade com zombando, se necessário, etc. Note-se também que nossos testes funcionais são automáticos, e está continuamente a correr, mas eles só demorar mais do que testes de unidade (que é uma das grandes vantagens de testes de unidade).

Eu gosto do exemplo Brick House vs.. Eu acho que o meu principal desenvolvedor está dizendo está testando as paredes da casa é o suficiente, você não precisa testar os tijolos individuais ...: -)

Answer 1

Em cima da minha cabeça

testes
• Unidade são repetíveis sem esforço. Escreva uma vez, milhares correr dos tempos, nenhum esforço humano exigido, e muito mais rápido do que o feedback que você recebe de um teste funcional
• Os testes de unidade testar pequenas unidades, por isso, apontar imediatamente para o "setor" correta em que o erro ocorre. Testes funcionais apontar erros, mas eles podem ser causados ??por uma abundância de módulos, mesmo em co-operação.
• Eu não chamaria uma mudança de interface "uma refatoração interior". mudanças de interface tendem a quebrar um monte de código, e (na minha opinião) forçar um novo circuito de teste em vez de nenhum.

Answer 2

testes de unidade são para devs para ver onde o código de falha

testes funcionais são para o negócio para ver se o código faz o que pediram

Answer 3

testes de unidade são para devs para ver onde o código de falha

testes funcionais são para o negócio para ver se o código faz o que pediram

testes de unidade estão verificando que você já fabricados seus tijolos corretamente

testes funcionais são a verificação de que a casa atende as necessidades do cliente.

São coisas diferentes, mas o último será muito mais fácil, se o primeiro foi realizado.

Answer 4

Pode ser muito mais difícil encontrar a fonte de problemas se um teste funcional falha, porque você está testando efetivamente toda a base de código de cada vez. Por outro lado, testes de unidade compartimentar as potenciais áreas problemáticas. Se todos os outros testes de unidade ter sucesso, mas este , você tem uma garantia de que o problema está no código que você está testando e não em outro lugar.

Answer 5

Os erros deverão ser pego mais cedo possível no ciclo de desenvolvimento -. Com erros passar de design para código, ou código de teste, ou (espero que não) teste para a produção aumenta o custo eo tempo necessário para corrigi-lo

Nossa unidade de loja Enforces teste só por isso (estou certo de que há outras razões, mas isso é o suficiente para nós).

Answer 6

Se você usar uma metodologia de programação extrema / Agile Development pura os testes de unidade são sempre necessários, pois são os requisitos para o desenvolvimento.

Em pura XP / Agile se faz todos os requisitos com base nos testes que vão ser realizados para a aplicação

• Testes funcionais -. Gerar requisitos funcionais
• Os testes de unidade -. Gerar funções ou exigências objeto

Além de que o teste de unidade pode ser usada para manter um controle persistente de requisitos funcionais.

i. Se você precisa mudar a forma de trabalho de uma função, mas os campos de entrada e saída de manter intocada. Em seguida, o teste de unidade é a melhor maneira de manter o rastreamento de possíveis problemas como você só precisa executar os testes.

Answer 7

Na TDD / BDD , testes de unidade são necessários para escrever o programa. O processo vai

teste de falha -> código -> teste de passagem -> refactor -> repeat

O artigo ligado também menciona os benefícios do TDD / BDD. Em resumo:

• Vem muito perto de eliminar o uso de um depurador (eu só usá-lo em testes agora e muito raramente para aqueles)
• O código não pode ficar confuso por mais de alguns minutos
• Exemplos de documentação para uma API built-in
• Forças solto acoplamento

O link também tem um (bobo) walk-through exemplo de TDD / BDD, mas é em PowerPoint (ew), então aqui 's uma versão HTML.

Answer 8

Suponha por um segundo que você já tem um conjunto exaustivo de testes funcionais que verificar cada caso de uso possível disponível e que você está considerando a adição de testes de unidade. Uma vez que os testes funcionais vai pegar todos os erros possíveis, os testes de unidade não vai ajudar a erros de captura. Existem no entanto, algumas desvantagens de se utilizar testes funcionais exclusivamente em comparação com uma combinação de testes unitários, testes de integração e testes funcionais.

• Os testes de unidade correr mais rápido. Se você já trabalhou em um projeto grande, onde o conjunto de testes leva horas para ser executado, você pode entender porque testes rápidos são importantes.
• Na minha experiência, em termos práticos, testes funcionais são mais propensos a ser esquisito. Por exemplo, às vezes navegador capivara-webkit decapitado só não pode chegar ao seu servidor de teste, por algum motivo, mas você está de gerência e ele funciona bem.
testes
• unitários são mais fácil de depurar. Assumindo que o teste de unidade travou um bug, é mais fácil e mais rápido para identificar exatamente onde está o problema.

Por outro lado, supondo que você decidir apenas manter seus testes funcionais e não adicionar quaisquer testes de unidade

• Se você precisar re-arquiteto de todo o sistema, você pode não ter que reescrever todos os testes. Se você tivesse testes de unidade, muitos deles provavelmente será excluído ou reescrito.
• Se você precisar re-arquiteto de todo o sistema, você não precisa se preocupar com regressões. Se você se baseou em testes de unidade para casos de canto capa, mas você foi forçado a excluir ou reescrever esses testes de unidade, seus novos testes de unidade são mais propensos a ter erros nelas do que o antigo testes de unidade.
• Uma vez que você já tem o ambiente de teste funcional configurar e de ter obtido sobre a curva de aprendizagem, escrever testes funcionais adicionais é muitas vezes mais fácil de escrever e muitas vezes mais fácil de escrever corretamente do que uma combinação de testes unitários, testes de integração e testes funcionais .