No PDC tivemos um painel de discussão sobre "O futuro do Teste Unitário". A maior parte da conversa focou em mocking. Foi um consenso geral frameworks de mock estão sendo super utilizados.
A teoria é a seguinte. Freqüentemente, implementar todas as interfaces necessárias é tedioso ou consome muito tempo. Então para tornar as coisas mais fáceis, as pessoas apelam para os frameworks de mocking. Isso apenas esconde o problema raiz, que é uma API muito complexa.
Um tema popular foi a diferença entre "teste de desenvolvedor" e teste que todo mundo faz. A idéia de que desenvolvedores escrevem somente testes unitários era freqüente na discussão. Testar de acordo com os requisitos, testes de aceitação, testes de integração e todas as outras formas de teste são problemas de alguém fora do desenvolvimento.
Isso ressalta uma incompreensão na comunidade de testes unitários. Especialmente, o pressuposto de que todos os desenvolvedores têm um time de QA para cuidar de todos os outros tipos de teste. Infelizmente, mesmo empresas multimilionárias freqüentemente não possuem um time de QA, deixando todo o teste para o desenvolvedor e o usuário final.
A principal desculpa para não suportar mais tipos de testes foi a velocidade. Testes unitários já são lentos e, portanto não há espaço para testes mais lentos que incluem comunicação via rede. Ainda pior é o fato de que nenhuma outra opção foi considerada.
Por exemplo, testes unitários podem ser inteligentes. É possível usar os resultado de cobertura de código para executar os testes somente para os códigos que mudaram. Mudar uma classe não deve exigir que você execute a suíte de teste inteira. O termo "teste unitário " implica que você pode testar somente um pequeno pedaço.
Outra possibilidade que não tem sido discutida é alavancar a programação distribuída. O código e os testes podem ser rapidamente carregados para diversos servidores e executados neles. Nós já temos toda a tecnologia necessária para execução de integração contínua.
No começo do painel, reconheceu-se que bancos de dados estão sendo negligenciados. A maioria dos desenvolvedores de banco de dados tem pouco ou nenhum conceito sobre testes unitários e há pouquíssimas ferramentas para suportá-los. Mais perturbador, nem foram questionados para vir à mesa do painel. Infelizmente isso foi tudo que foi dito sobre eles. Em nenhum momento o painel ofereceu opções reais para corrigir os problemas sociais.
Do lado positivo, houve alguma discussão sobre usar ferramentas de modelagem para tornar os testes unitários mais fáceis. Há muitas opções aqui como iniciar no nível de contratos. Os contratos poderiam então ser usados pelos geradores de código para escrever os testes. Obviamente isso não seria uma solução 100%, mas iria reduzir o esforço em cenários comuns.
Outra idéia promissora foi a de delta state management. A maioria das pessoas assume que um teste de contas começa com $100 e depois da transação só tem $80. A alternativa é primeiro ler o balanço atual e então checar para ver se houve a redução de $20. Desta forma um reconfiguração completa do ambiente de teste não necessária para cada execução.