Continuos Integration e TDD no mundo Real
Quem já trabalhou em projetos em produção com clientes e constantemente precisou lançar novas features se deparou com o problema destes lançamentos, seja quebrando código que já está funcionando ou na dificuldade de implementação das novas demandas.
Muito se fala em entrega continua, para que o projeto nunca fique obsoleto, mas até quando você vai conseguir fazer entregas de novas demandas sem que quebre o que já está rodando? Para isso foram criadas ferramentas que auxiliam e otimizam o trabalho de testes.
CI (Continuos Integration)
Antes de continuarmos, precisamos esclarecer alguns pontos, o primeiro, o que é continuos integration.
“A integração contínua é um termo originado na metodologia ágil XP e utilizado em diversas metodologias, consistindo em algo simples: o desenvolvedor integra o código alterado e/ou desenvolvido ao projeto principal na mesma frequência com que as funcionalidades são desenvolvidas, sendo feito muitas vezes ao dia ao invés de apenas uma vez. O objetivo principal de utilizar a integração contínua é verificar se as alterações ou novas funcionalidades não criaram novos defeitos no projeto já existente. A prática da integração contínua pode ser feita através de processos manuais ou automatizados, utilizando ferramentas como o Jenkins, Hudson entre outros.” — http://www.devmedia.com.br/integracao-continua-uma-introducao-ao-assunto/28002
Pensando nisso, nada mais é fazer entregas sem afetar o que já existe, utilizando ferramentas para isso.
TDD (Test Driven Development)
E o TDD? Vocês já devem ter ouvido falar alguma vez, e até brincado com esta metodologia. Vamos as definições:
“Test Driven Development (TDD) ou em português Desenvolvimento guiado por testes é uma técnica de desenvolvimento de software que baseia em um ciclo curto de repetições: Primeiramente o desenvolvedor escreve um caso de teste automatizado que define uma melhoria desejada ou uma nova funcionalidade. Então, é produzido código que possa ser validado pelo teste para posteriormente o código ser refatorado para um código sob padrões aceitáveis.” — https://pt.wikipedia.org/wiki/Test_Driven_Development
De acordo, com essa definição podemos dizer que devemos testar um código antes dele existir e assim construir o código que passe neste teste da forma mais simples possível.
Dada essas definições, vamos ao um caso real:
Utilizando o projeto Winners, vou mostrar a vocês, como TDD e CI com Scrutinizer pode salvar vocês de colocar código no branch master quebrado, e também não enviar-lo para o ambiente de produção.
Trecho atual do código de rotas que vamos mexer:
Resultado dos testes rodados manualmente no meu local:
Vamos agora adicionar o teste para verificamos o verbo GET em Orders.
Teste adicionado, explicando um pouco deste código, ele gera um usuário, logo após cria um produto, cria o pedido e tenta capturar este pedido gerado e espera um código 200. Vamos verificar o que aconteceu nos testes.
Já retornou um erro, o que está dizendo é que o código 200 que estamos esperando não retornou, e retornou um 405, isso porque ainda não adicionamos a rota no arquivo. Vou adicionar e rodar novamente os testes.
Aparentemente inofensivo não acham? Um rota GET que não vai danificar as outras rotas. Mas vamos rodar os testes e ver como o resto do código se comportou com esta modificação.
Por causa de um endpoint novo, quebramos 3 testes. Somente rodando os testes localmente já pegamos isso, e podemos resolver no ambiente de desenvolvimento, mas se caso o desenvolvedor não rode os testes e faça este commit, o que vai acontecer com o Scrutinizer\Travis. Vamos criar o branch e o Pull Request?
No próprio commit do branch, já notamos que ocorreu um erro.
No pull request, essa informação já fica mais explicativa e ainda podemos acessar a ferramenta e obter mais detalhes.
E com isso você pode escolher em fazer o merge ou não, e se ainda assim, isso passar para o ambiente master, você pode automatizar o deploy com as API’s do Scrutinizer e do Travis e só fazer o deploy se tudo estiver certo, se tiver dificuldades em fazer o deploy automatizado, com Laravel e outros frameworks PHP, você pode usar o Deployer. O automatizador da CiaWN está disponível no GitHub.
https://github.com/ciawn/deploy
Em geral, era isso que queria passar para vocês hoje, e vocês qual é sua opinião sobre TDD? Continuos Integration? Já estão usando? Vantagens? Desvantagens?
Compartilhe sua opinião, e compartilhe o artigo ❤
