Como desenvolvedores de software trabalhando em equipe, você usa muitas ferramentas que fornecem colaboração entre os membros da equipe. Uma dessas ferramentas é o Jenkins, que fornece integração contínua. Você pode configurar seu servidor de integração da maneira que inicia uma construção de projeto quando ocorre uma modificação no repositório de controle de origem. A construção pode ser bem-sucedida ou falhar. No último caso, isso pode acontecer por vários motivos, um dos quais é quebrar o código existente. Qual é a sua garantia de que a modificação ou adição de código não quebrará sua base de código?
A resposta a esta pergunta são os testes de unidade, eles permitem que você verifique se sua refatoração quebra o código existente ou não. Isso é feito executando os testes de unidade já implementados antes de confirmar sua modificação. Como exemplo, considere modificar um módulo X existente, a modificação consiste em adicionar um novo caso de teste de unidade e modificar uma classe existente. Para verificar sua modificação, você executa o novo caso de teste; se for aprovado, isso nunca significa que sua modificação não quebrou seu código. Para ter certeza disso, você deve executar todos os testes contidos no módulo X e não apenas o novo, se todos passarem, você terá a confirmação de que seu código está em bom estado.
A execução dos testes deve ser feita manualmente. Infelizmente, não existe uma maneira automática de fazer isso como no caso de commit ao usar um software SCM como Subversion — por exemplo, se você enviar arquivos desatualizados, o Subversion irá impedi-lo de fazer isso e o commit irá falhar.
Finalmente, você tem que ser extremamente cuidadoso ao chegar ao ponto de confirmação. Como você não tem uma ferramenta que o impeça de fazer commit quando seu código estiver quebrado, você não deve se esquecer de testar o módulo inteiro antes de fazer isso.