Surely, by the time something gets committed to master, a developer has already run all the unit tests before and fixed any errors that might've occurred with their new code.
Ou não. Pode haver muitas razões pelas quais isso pode acontecer:
- O desenvolvedor não tem disciplina para fazer isso
- Eles esqueceram
- Eles não confirmaram tudo e empurraram um conjunto de confirmações incompleto (obrigado Matthieu M.
- Eles só executaram alguns testes, mas não o pacote inteiro (obrigado nhgrif )
- Eles testaram em suas filiais antes da fusão (obrigado nhgrif * 2)
Mas o verdadeiro ponto é executar os testes em uma máquina que não seja a máquina do desenvolvedor. Um que esteja configurado de maneira diferente.
Isso ajuda a detectar problemas em que testes e / ou código dependem de algo específico de uma caixa de desenvolvedor (configuração, dados, fuso horário, localidade, o que for).
Outras boas razões para o CI construir testes para executar:
- Teste em plataformas diferentes das principais plataformas de desenvolvimento, o que pode ser difícil para um desenvolvedor fazer. (obrigado TZHX )
- Aceitação / Integração / De ponta a ponta / Testes de execução muito longa podem ser executados no servidor de IC que normalmente não seriam executados em uma caixa de desenvolvedor. (obrigado Ixrec )
- Um desenvolvedor pode fazer uma pequena alteração antes de pressionar / confirmar (pensando que essa é uma alteração segura e, portanto, não está executando os testes). (obrigado Ixrec * 2)
- A configuração do servidor de IC geralmente não inclui todas as ferramentas e configurações do desenvolvedor e, portanto, está mais próxima do sistema de produção
- Os sistemas de CI criam o projeto do zero toda vez, o que significa que as construções são repetíveis
- Uma alteração de biblioteca pode causar problemas no recebimento de dados - um servidor de IC pode ser configurado para criar bases de código dependentes all , não apenas na biblioteca