meus anos de experiência em desenvolvimento de software sugerem que, na prática, não pode funcionar.
Tentaste? Dave e eu escrevemos o livro com base em muitos anos de experiência coletiva, tanto de nós mesmos como de outras pessoas seniores da ThoughtWorks, realmente fazendo as coisas que discutimos. Nada no livro é especulativo. Tudo o que discutimos foi testado e testado, mesmo em grandes projetos distribuídos. Mas não sugerimos que você aceite isso com fé. Claro que você deve tentar e escreva o que acha que funciona e o que não funciona, incluindo o contexto relevante, para que outros possam aprender com suas experiências.
Entrega contínua tem um grande foco em testes automatizados. Gastamos cerca de 1/3 do livro falando sobre isso. Fazemos isso porque a alternativa - teste manual - é cara e propensa a erros e, na verdade, não é uma ótima maneira de criar software de alta qualidade (como Deming disse: "Cesse a dependência da inspeção em massa para obter qualidade. Melhore o processo e melhore a qualidade"). o produto em primeiro lugar ")
A cobertura total do teste é impossível. Você precisa dedicar muito tempo - e tempo é dinheiro - para cada pequena coisa. Isso é valioso, mas o tempo pode ser gasto contribuindo para a qualidade de outras maneiras.
É claro que a cobertura total do teste é impossível, mas qual é a alternativa: zero cobertura do teste? Há uma troca. Em algum lugar no meio está a resposta correta para o seu projeto. Concluímos que, em geral, você deve gastar cerca de 50% do seu tempo criando ou mantendo testes automatizados. Isso pode parecer caro até você considerar o custo de testes manuais abrangentes e corrigir os erros que surgem para os usuários.
Algumas coisas são difíceis de testar automaticamente. Por exemplo, GUI. Mesmo o Selenium não informa se a sua GUI é instável.
Claro. Confira o quadrante de teste de Brian Marick. Você ainda precisa executar testes exploratórios e testes de usabilidade manualmente. Mas é para isso que você deve usar seus seres humanos caros e valiosos - não para testes de regressão. A chave é que você precisa implantar um pipeline de implantação para que você só se preocupe em executar valiosas validações manuais em compilações que passaram por um conjunto abrangente de testes automatizados. Assim, você reduz a quantia gasta em testes manuais e o número de bugs que chegam a testes ou produção manuais (quando são muito caros de consertar). O teste automatizado feito da maneira certa é muito mais barato durante o ciclo de vida do produto, mas é claro que é um gasto de capital que se amortiza com o tempo.
É difícil testar o acesso ao banco de dados sem equipamentos volumosos, e mesmo isso não cobre casos estranhos de esquina no armazenamento de dados. Da mesma forma segurança e muitas outras coisas. Somente o código da camada de negócios é efetivamente testável por unidade.
O acesso ao banco de dados é testado implicitamente pelos testes de aceitação funcional baseados em cenários de ponta a ponta. A segurança exigirá uma combinação de teste automatizado e manual - teste de penetração automatizado e análise estática para encontrar (por exemplo) excedentes de buffer.
Mesmo na camada de negócios, a maioria dos códigos não possui funções simples cujos argumentos e valores de retorno podem ser facilmente isolados para fins de teste. Você pode gastar muito tempo criando objetos simulados, que podem não corresponder às implementações reais.
É claro que os testes automatizados são caros se você criar seu software e seus testes mal. Eu recomendo verificar o livro "crescente software orientado a objetos, guiado por testes" para entender como fazê-lo corretamente, para que seus testes e código sejam mantidos ao longo do tempo.
Os testes de integração / funcionais complementam os testes de unidade, mas demoram muito tempo para serem executados porque geralmente envolvem a reinicialização de todo o sistema em cada teste. (Se você não reinicializar, o ambiente de teste será inconsistente.)
Um dos produtos em que eu trabalhava tem um conjunto de 3.500 testes de aceitação de ponta a ponta que levam 18 horas para serem executados. Executamos em paralelo em uma grade de 70 caixas e obtemos feedback em 45m. Ainda mais do que o ideal, é por isso que o executamos como o segundo estágio no pipeline após a execução dos testes de unidade em alguns minutos, para não desperdiçarmos nossos recursos em uma construção da qual não temos um nível básico de confiança em.
A refatoração ou qualquer outra alteração quebra muitos testes. Você gasta muito tempo consertando-os. Se é uma questão de validar alterações significativas nas especificações, tudo bem, mas geralmente os testes são interrompidos devido a detalhes de implementação de baixo nível sem sentido, e não a coisas que realmente fornecem informações importantes. Freqüentemente, o aprimoramento é voltado para o retrabalho interno do teste, não para realmente verificar a funcionalidade que está sendo testada.
Se o seu código e testes estiverem bem encapsulados e fracamente acoplados, a refatoração não interromperá muitos testes. Descrevemos em nosso livro como fazer a mesma coisa também para testes funcionais. Se seus testes de aceitação forem interrompidos, isso significa que você está perdendo um ou mais testes de unidade; portanto, parte do CD envolve melhorar constantemente sua cobertura de testes para tentar encontrar erros no início do processo de entrega, onde os testes são mais detalhados e os os erros são mais baratos de corrigir.
Os relatórios de campo sobre bugs não podem ser facilmente combinados com a micro-versão precisa do código.
Se você estiver testando e lançando com mais frequência (parte do ponto do CD), é relativamente simples identificar a alteração que causou o bug. O objetivo principal do CD é otimizar o ciclo de feedback para que você possa identificar os erros o mais rápido possível após o check-in no controle de versão - e de fato, preferencialmente antes do check-in (é por isso que executamos os testes de construção e unidade antes do check-in).