TDD, Quais são suas técnicas para encontrar testes bons?

Question

Eu estou escrevendo um aplicativo web simples usando LINQ to SQL como meu DataLayer como eu gosto Linq2Sql muito. Eu tenho lido um pouco sobre DDD e TDD ultimamente e queria dar-lhe um tiro.

Em primeiro lugar parece-me que Linq2Sql e DDD não ir junto muito grande. Meu outro problema é encontrar provas, eu realmente achar que é muito difícil de definir bons testes, então eu queria perguntar, qual é sua melhores técnicas para descobrir casos de teste bom.

Answer 1

descoberta do caso de teste é mais uma arte do que uma ciência. No entanto orientações simples incluem:

• O código que você sabe ser frágil / fraco / propensos a quebrar
• Siga o cenário de usuário (o que o usuário vai fazer) e ver como ele vai tocar o seu código (Muitas vezes isso significa depurá-lo, outras vezes de perfil, e outras vezes isso significa simplesmente pensar sobre o cenário) - quaisquer que sejam pontos em sua código se tocado pelo usuário, esses são a maior prioridade aos testes de escrita contra.
• Durante o seu próprio desenvolvimento os testes que você executou que resultaram em erros que você encontrou -. Testes de gravação para evitar o código regredindo novamente com o mesmo comportamento

Existem vários livros sobre como escrever casos de teste lá fora, mas a menos que você estiver trabalhando em uma grande organização que requer casos de teste documentados, a sua melhor aposta é a de pensar em todas as peças em seu código que você não gosta (que não são "pura") e certifique-se que você pode testar os módulos completamente.

Answer 2

Bem, passando pela interpretação padrão de TDD é que os testes unidade seu desenvolvimento. Então, em essência você começa com o teste. Ele irá falhar, e você vai escrever o código até que o teste passa. Por isso é tipo de impulsionado por suas necessidades, no entanto você vai sobre o recolhimento desses. Você decide o que seu app / recurso precisa fazer, escrever o teste, então o código até que ele passa. Claro, existem muitas outras técnicas, mas esta é apenas uma declaração breve sobre o que normalmente é pensado no mundo do TDD.

Answer 3

Pense . Leia o código. Pergunta-se: por exemplo, pode este ponteiro nunca será NULL aqui? O que acontece se este método é chamado antes da inicialização?

Não faça suposições como " este arquivo estará sempre lá ". Teste.

Pense em casos extremos, limites, valores negativos, estouros de ...

Bug muitas vezes são agrupados por cluster. Olhe ao seu redor quando você encontrar um. Também olhar para o mesmo tipo de erro em outros locais.

Answer 4

Defina a sua mente para o objetivo real de testes:. Erros Encontrando

Seja criativo em imaginar o que poderia fazer seu programa falhar.

Os testes devem encontrar erros, não confirmam que o seu programa é OK.

Answer 5

Eu regularmente escrever testes para APIs de terceiros. Dessa forma, quando as atualizações da API, eu sei se eu vou quebrar ou não.

Answer 6

Eu acho que esta é uma técnica útil:

Usando contratos e consultas booleanas para melhorar a qualidade de geração de teste automático

---

Referência: Lisa (Ling) Liu, Bertrand Meyer e Bernd Schoeller, Usando contratos e consultas booleanas para melhorar a qualidade de geração de teste automático , em processos de TAP: testes E Provas , ETH Zurich, 5-6 de fevereiro de 2007, eds. Yuri Gurevich e Bertrand Meyer, Lecture Notes in Computer Science, Springer Verlag de 2007.