É difícil e irrealista manter grandes dados simulados. É ainda mais difícil quando a estrutura do banco de dados sofre alterações.
Falso.
O teste de unidade não requer dados simulados "grandes". Requer dados simulados suficientes para testar os cenários e nada mais.
Além disso, os programadores verdadeiramente preguiçosos pedem aos especialistas no assunto que criem planilhas simples dos vários casos de teste. Apenas uma planilha simples.
Em seguida, o programador preguiçoso escreve um script simples para transformar as linhas da planilha em casos de teste de unidade. É bem simples, realmente.
Quando o produto evolui, as planilhas dos casos de teste são atualizadas e novos testes de unidade gerados. Faça isso o tempo todo. Realmente funciona.
Mesmo com o MVVM e a capacidade de testar a GUI, é preciso muito código para reproduzir o cenário da GUI.
O que? "Reproduzir"?
O objetivo do TDD é projetar coisas para a testabilidade (desenvolvimento do test drive). Se a GUI é tão complexa, ela precisa ser reprojetada para ser mais simples e testável. Mais simples também significa mais rápido, mais sustentável e mais flexível. Mas, na maioria das vezes, mais simples significa mais testável.
Tenho experiência que o TDD funciona bem se você o limitar à lógica de negócios simples. No entanto, é difícil testar uma lógica de negócios complexa, pois o número de combinações de teste (espaço de teste) é muito grande.
Isso pode ser verdade.
No entanto, pedir aos especialistas no assunto que forneçam os casos de teste principais de uma forma simples (como uma planilha) realmente ajuda.
As planilhas podem se tornar bastante grandes. Mas tudo bem, já que usei um script Python simples para transformar as planilhas em casos de teste.
E. Eu tive que escrever alguns casos de teste manualmente porque as planilhas estavam incompletas.
Contudo. Quando os usuários relataram "bugs", simplesmente perguntei qual caso de teste na planilha estava errado.
Naquele momento, os especialistas no assunto corrigiam a planilha ou adicionavam exemplos para explicar o que deveria acontecer. Os relatórios de erros podem - em muitos casos - ser claramente definidos como um problema de caso de teste. De fato, pela minha experiência, definir o bug como um caso de teste quebrado torna a discussão muito, muito mais simples.
Em vez de ouvir os especialistas tentando explicar um processo de negócios super complexo, eles precisam produzir exemplos concretos do processo.
O TDD exige que os requisitos sejam 100% corretos. Nesses casos, pode-se esperar que requisitos conflitantes sejam capturados durante a criação de testes. Mas o problema é que esse não é o caso em cenários complexos.
Não usar o TDD exige absolutamente que os requisitos sejam 100% corretos. Alguns afirmam que o TDD pode tolerar requisitos incompletos e variáveis, onde uma abordagem não-TDD não pode funcionar com requisitos incompletos.
Se você não usar TDD, a contradição será encontrada tarde na fase de implementação.
Se você usa TDD, a contradição é encontrada anteriormente quando o código passa em alguns testes e falha em outros testes. De fato, o TDD fornece uma prova de uma contradição no início do processo, muito antes da implementação (e argumentos durante o teste de aceitação do usuário).
Você tem código que passa em alguns testes e falha em outros. Você olha apenas para esses testes e encontra a contradição. Isso funciona muito, muito bem na prática, porque agora os usuários precisam discutir sobre a contradição e produzir exemplos consistentes e concretos do comportamento desejado.