Compilação Rápida e Compilação Completa

Compilação Rápida / Compilação Completa

1. Contexto
2. Solução
3. Motivação
4. Ampliação

Contexto

Tem um sistema grande com milhares e milhares de testes. As suas compilações vão ficando cada vez mais lentas e começão a tornar-se um peso para a equipa. Está a trabalhar numa nova funcionalidade e uma grande parte dos testes testa algo onde não toca há meses. Continuando a desejar a segurança de não regredir em funcionalidade existente gasta várias horas do dia a testar algo que é pouco provável quebrar.

Solução

Criar duas compilações: uma compilação rápida e uma compilação completa. Mantenha uma lista de teste excluídos e exclua a maior parte dos testes da compilação rápida e faça com que esta seja realmente rápida, à volta de 10 minutos. Deixe só coisas que sejam muito prováveis quebrar, coisas em que esteja a trabalhar e coisas sensíveis. Não perca tempo a classificar teste, penso só se é provável que quebrem ou não. A compilação completa percorre todos os testes.

Execute a compilação rápida como parte de cada commit, antes do commit e como parte da verificação da integração contínua da compilação.

Execute a compilação completa menos frequentemente. À noite, algumas vezes ao dia ou numa máquina diferente executando em permanência (mas menos frequentemente visto sem obviamente mais lenta). Quando efectuar refactorizações grandes de componentes partilhado deve provavelmente executar uma compilação completa.

Adicionalmente mantenha uma lista de testes incluídos nas compilações rápidas, quando um teste falha na compilação completa deve ser de imediato adicionado à lista de testes a executar na compilação rápida e ser executado na compilação rápida seguinte.

Motivação

A função da integração contínua é dar uma resposta de imediato. Quando mais rápida for esta resposta mais rapidamente é possível corrigir o problema e seguir. Os ganhos de produtividade de uma compilação de 10 minutos é de uma ordem de grandeza mais elevada do que o de uma compilação de 1 hora.

Quando tem uma compilação grande e lenta essencialmente perde essa resposta rápida. Para voltar a ter essa resposta rápida constrói uma compilação rápida que irá potencialmente apanhar uma grande parte das falhas possíveis. Não sacrifica nenhuma segurança pois a compilação completa ainda é executada e protege-o contra regressões.

Esta segurança pode ser melhorada adicionando automaticamente testes que tenham falhado recentemente logo que falhem na compilação completa. Se falhou recentemente pode voltar a falhar, é óbvio. Também assegura que os programadores tratem de corrigir o teste visto não deverem efectuar commit com uma compilação rápida com defeito.

Ampliação

Este padrão pode ser ampliado incluindo várias camadas de compilações. Por exemplo pode ter camadas para compilação rápida, compilação completa e depois um conjunto completo de testes funcionais. Os testes funcionais com a totalidade dos sistemas de retaguarda ligados e activos podem ser extremamente lentos. Não é fora do comum ter conjuntos destes a correrem mais de 24 horas seguidas.

Numa das sessões do Google Edu, a responsável pelos testes dizia que considerava que o mínimo para estes testes serem executados era de cerca de 1 semana (pois o padrão de acessos varia com o dia da semana e a hora do dia).