Testes automatizados como parte de uma cultura de desenvolvimento-Ensaio 1
Ensaios sobre a aplicação de testes automatizados às varias etapas do desenvolvimento de software
A wikipedia define Ensaio como:
Ensaio é uma obra de reflexão que versa sobre determinado tema, sem que o autor pretenda esgotá-lo, exposta de maneira pessoal ou mesmo subjetiva.
fonte: https://pt.wikipedia.org/wiki/Ensaio_(literatura)
E é exatamente o que quero propor com o documento que você esta lendo no momento. Refletir, com você, leitor, convidando-o a pensar sobre os pontos aqui discorridos e também a colaborar com a construção de um estudo mais aprofundado, que podemos, então, escrever como fruto dessa reflexão.
O tema desses ensaios nada mais é do que Testes Automatizados. Discorreremos sobre definições, abordagens e práticas. Seja bem-vindo e sinta-se a vontade para enriquecer o presente documento com comentários, sugestões e perguntas.
Roadmap
Separei cada ensaio em um post próprio, por motivos de: isto está ficando bem grande.
- Ensaio 1: Somos todos devs(o que você está lendo agora)
- Ensaio 2: O valor que o seu teste entrega(breve)
- Ensaio 3: TDD - Feedbacks automatizados(breve)
- Ensaio 4: Refatorando testes (breve)
- Ensaio 5: Lidando com legado (breve)
- Ensaio 6: Documentando bugs (breve)
- Ensaio 7: Testes e devops (breve)
Somos Todos Devs
A necessidade de testar é normalmente dolorida para nós desenvolvedores.
Sentimos essa dor por estarmos acostumados a testar manualmente algumas vezes. Fazemos esses testes para descobrir se terminamos a tarefa, se está pronto para review, se está na hora de mandar para o QA. Mas, e os testes automatizados?
Ah, isso é coisa de QA — o programador dentro de nós
Alguns entendem que testes automatizados são importantes, mas vão criar os testes depois que estão confortáveis, com o resultado final, quase como se o dev assumisse um papel de auto-qa. Não é algo de todo ruim. Mas, lá no fundo, esse papel é secundário, o dev que faz isso ainda se orgulha muito mais do seu código do que do teste que teve de escrever depois.
Lá no fundo, acreditamos que a qualidade é preocupação do QA. E, então, o dev pensa que, se escreve um teste já é ótimo, é uma boa prática. Mas, nesse momento, ele não acredita que está executando uma atividade de desenvolvimento. Ao pensar assim o QA ao escrever o BDD, o e2e, também não está executando uma atividade de desenvolvimento, isto é, o não é um dev também.
Bom, meu amigo, mas a verdade é que a batata é sua, esteja quente ou fria, esteja no seu prato, ou no do QA, ou no do PM/PO/PMO. Vocês todos são parte da cozinha e serão cobrados pela qualidade da comida que estão entregando e …
…SOMOS TODOS DEVS.
Os testes automatizados são tão frutos de desenvolvimento quanto a feature que você desenvolveu. Logo somos todos devs, ponto. O que separa um dev front-end de um dev back-end é a mesma coisa que separa um dev de um QA, a saber, o objeto de seu desenvolvimento.
Inclusive é levando esse conceito de somos todos devs (ou engenheiros) que surge o SRE, não aplicado ao QA em si, mas ao time de suporte de operações e ocorrências.
Bom, mas e o kiko?
E o que que a Kovi tem a ver com isso?
Testes automatizados na Kovi
Há muito o que realizarmos nesse quesito aqui. Nossa esteira e processo de deploy contininuo já é bem eficiente. Na minha segunda semana eu já tinha colocado código em produção, isso por que, na minha época, o onboarding levava algo em torno de 1 semana. Hoje, com um dia de casa um dev já tem seu ambiente pronto e está apto a nos ajudar.
Mas ainda sobre testes: estamos começando uma cultura. Quanto mais nos tornarmos donos dessa codebase e a tratarmos como a fonte de onde saem os maiores desafios e aprendizados, todos ganharemos. Para contribuir com isso, estou trazendo uma série de artigos que abordam o meu jeito de trabalhar. Entendo que nem todos concordarão com as minhas praticas ou mesmo com os princípios que abordo.
No fim, a minha proposta é a de iniciarmos uma cultura de desenvolvimento guiado por testes. Mas isso fica para o próximo ensaio, onde falaremos mais detalhadamente sobre definições e abordagens na hora de se fazer TDD.
Teh… Deh.. Dehhhhhh! Meus amigos, TDD.
