Atuação Do QA No TDD

Como já conhecemos a jornada como QA e Tester se modificou ao longo do tempo, saindo do tester de mainframe, até os dias atuais com testes em blockchain, IoT, shift left testing e etc. O QA como todas as área dentro de TI não pode dar o luxo de aguardar as mudanças e deve sempre se atentar em todos os pontos do desenvolvimento de software.

Partindo dessa premissa o QA utilizando do shift left testing deve sempre auxiliar o time a desenvolver primeiro uma cultura de qualidade e posteriormente estar auxiliando no desenvolvimento de software e aqui entra a importância do QA conhecer de TDD.

TDD

TDD, ou “Test-Driven Development” (Desenvolvimento Orientado por Testes), é uma abordagem na programação de software que enfatiza a criação de testes antes de escrever o código real de um programa. Seu foco é baseado em um ciclo na qual primeiro é desenvolvido o caso de teste para determinada parte do código, faça o código passar no teste e por fim refatore. A imagem abaixo traz um detalhamento desse ciclo.

Imagem retirada do artigo TDD e seu significado

A partir da imagem podemos detalhar melhor o fluxo, baseado nas cores:

Vermelho: Primeiro, você cria um teste que descreve o comportamento que deseja que o seu código tenha. Esse teste geralmente falha no início, pois o código real ainda não foi escrito.
Azul: Em seguida, você escreve o código mínimo necessário para fazer o teste passar. Isso significa que você está implementando apenas o suficiente para que o teste seja bem-sucedido. Se nesse caso o teste falhar, você continua a ajustar o código até que o teste passe.
Verde: Depois que o teste passa, você pode refatorar, ou seja, melhorar o código sem alterar o comportamento observado. Isso ajuda a manter o código limpo e organizado.

Bom, conhecemos um pouco do fluxo e parte principal do TDD que é seu ciclo de criação, execução e correção do código, e nesse momento você pode se perguntar, “Por que o desenvolvedor não curte TDD?”.

Essa pergunta pessoal baseia-se muito na cultura de um time e de uma empresa, somos humanos e gostamos de costumes e rotinas, nesse sentido a maioria dos desenvolvedores (e me incluo nessa lista) aprendemos que primeiramente devemos desenvolver a determinada funcionalidade e posteriormente realizar os testes em específico, o TDD é uma mudança de mindset e que deve ser trabalhado em conjunto entre todos do time, caso você QA esteja nesse ponto de trazer o TDD para dentro do time trago alguns pontos que irá te auxiliar.

O primeiro ponto é promover uma cultura de qualidade em toda a equipe. Faça com que todos compreendam que a prática do TDD não é apenas sobre escrever testes, mas sobre criar software mais robusto e confiável.
Com o começo da implantação da cultura de qualidade use métricas de cobertura de testes para avaliar o quanto do seu código está sendo testado. Use ferramentas que possibilitem essa análise. Ainda dentro dessa camada crie desafios, para que o time encoraja para melhorar a qualidade dos testes e do código. Quem não gosta de ganhar um desafio? rsrs
Usando esses desafios inclua a criação de testes como parte integrante do fluxo de trabalho de desenvolvimento. Isso significa que antes de escrever qualquer código de produção, os desenvolvedores devem criar testes que descrevam o comportamento desejado. Aqui você pode usar os ritos para alinhar quais os testes, os testes são uma documentação viva que auxilia todos no entendimento do código.
Participe dos pair-programming e torne os testes parte do processo de revisão de código. Garanta que os testes sejam de alta qualidade e abrangentes, e que os desenvolvedores compreendam o código que estão revisando.
Com esses itens realizados, automatize a execução dos testes para que eles possam ser facilmente rodados toda vez que houver uma alteração no código. Utilize ferramentas de teste apropriadas para a linguagem e plataforma em que você está trabalhando.

A partir desse primeiro entendimento vamos conhecer o padrão de escrita de testes Triple AAA.

Padrão de escrita de testes Triple A

Dentre do completo guia da pirâmide de testes, um dos testes mais importantes é o teste unitário. Dentro dessa camada há muitas formas de você estar escrevendo seu teste, contudo o mais utilizado e mais prático de se aplicar é o triple A. Esse padrão vem das três etapas que possuem o nome começando com A (Arrange, Act e Assert), abaixo tem a explicação de cada parte:

Arrange: Nesta etapa nós configuramos tudo o que é necessário para que o nosso teste possa rodar, inicializamos variáveis e criamos os mocks.
Act: Esta etapa é onde rodamos de fato o nosso teste. Chamamos alguma função ou método que queremos por a prova.
Assert: Esta etapa é onde faremos nosso assert. É onde verificamos se a operação realizada na etapa anterior (Act) surtiu o resultado esperado. Assim sabemos se o teste passa ou falha.

Bom, após entendermos do Triple A, vamos realizar uma prática?

Photo by Blake Connally on Unsplash

Pratica

Para a prática é necessário primeiramente as seguintes ferramentas instaladas:

VSCode;
Node;

Com essas ferramentas instaladas em nossa máquina primeiro vamos criar o projeto node para isso escolha uma pasta para seu projeto e execute o comando npm init -ypara criarmos o package.json.

Após criado o projeto node, execute o comando npm install --save-dev jest.Após terminado a instalação vamos para a pratica.

Suponhamos que pegamos uma tarefa que o objetivo seja inverter uma palavra, logo de inicio já iríamos criar o arquivo para começar a codificar, contudo vamos usar o TDD que aprendemos na semana passada e criar o arquivo de teste. Nosso caso principal é com entrada de uma palavra a mesma deve voltar invertida, exemplo, adicionando banana deve voltar ananab.

Então abaixo nosso primeiro caso de teste.

test(‘Palavras normais e que deve voltar seu formato invertido’, () => {
//Arrange
const reverseString = require(’./reverseString.js’);
//Act
const string = reverseString(‘carro’);
//Assert
expect(string).toBe(‘orrac’);
expect(reverseString(‘banana’)).toBe(‘ananab’);
expect(reverseString(‘joao’)).toBe(‘oaoj’);
});

Show, após criarmos nosso caso de teste vamos para o segundo ciclo, criar a função para inverter as string.

function reverseString(str) {
var newString = “”;
for (var i = str.length - 1; i >= 0; i–) {
newString += str[i];
}
return newString;
}

Criado meu código para inverter uma string ao invés de executarmos o código e ficarmos fazendo várias tentativas, podemos executar nosso teste criado e validar se nossa lógica está correta, para isso execute o comando npm run test. Caso esteja correto o código irá avisar que passou os testes, caso tenha um erro, volta-se para o ciclo de desenvolvimento até que passe o teste.

Aqui nesse momento quando passou os testes podemos pensar, terminei bora pra próxima tarefa, calma jovem, você está pulando uma etapa muito importante que é de refatoração. Se você perceber, no código acabei usando um laço de repetição para percorrer a minha string, contudo, sabemos que existe métodos prontos em javascript como o reverse() e join(). Assim vamos para a etapa de refatoração primeiramente usando o reverse ao invés do laço de repetição e posteriormente usando o join() para unir o texto que foi separado no comando split(). O código ficando no formato abaixo.

const reverseString = (string) => string.split(’’).reverse().join(’’);

Acabamos de simplificar o código de 7 linhas para somente 1 linha, deixando o código mais limpo e com uma complexidade baixa de leitura.

Para não se estender muito o artigo*,* criei mais um exemplo de calculadora, para você ver o projeto inteiro segue o link do Github.

A partir desse entendimento da prática de como desenvolvemos código utilizando TDD, abaixo trago alguns exemples práticos para que gere insights para você aplicar na empresa que atua, então vamos lá?

Um dos primeiros pontos que o QA deve observar no time é a questão da maturidade que o time se encontra, se o time é recente acredito que você conseguirá aplicar inicialmente a prática do TDD para que gere uma cultura baseada na criação de testes. Caso o time já tenha uma maturidade já desenvolvida baseada na entrega a todo custo, nesse caso é interessante você se basear em trazer aos poucos a cultura de qualidade e mostrando os benefícios do TDD e como aplicar.

Após você conhecer o ambiente que está trabalhando, use toda sua comunicação para trazer o time de desenvolvimento para seu lado, escutando as dores que eles sentem para desenvolver, como que é a forma de entrega do time, cadência das demandas, fazendo isso você entenderá como está o time e se o TDD funcionara para esse momento, caso você perceba que não é o momento você já conseguiu uma confiança com o time de engenharia por ter ouvido e entendido a dores deles.

Caso dê match que é o momento para o TDD, use os esforços para mostrar a importância do TDD e aplicar em casos iniciais com um engenheiro em específico. Nesse momento trabalhe em conjunto com ele para entender o desenvolvimento e auxiliar a pensar nos tipos de teste que ele pode realizar. Um exemplo nessa parte é unir o framework de metodologia ágil com o TDD, abaixo segue um exemplo prático.

A maioria dos times realiza um refinamento e planeja o tamanho das tarefas, se a tarefa possuir um tamanho muito grande e o time perceber que não da para dividir, combine com o time que essa tarefa é interessante ser aplicado o TDD como garantia da entrega com segurança, bem como você estará auxiliando o engenheiro nesse desenvolvimento. Caso tenha receio de usar em tarefas grandes, você pode inverter a lógica para tarefas pequenas e trazer o time como todo para aplicar TDD.

Sempre recorde que a evolução deve ser constante e com muito feedback, que os testes criados sejam executados a todo instante que a comunicação é a melhor forma de unir a teoria e prática.

É isso pessoal, hoje conhecemos um pouco sobre a participação do QA na escrita de código utilizado TDD e como aplicar nos times que atua.

Para ter conteúdos semanais sobre Tecnologia e Qualidade de Software, assine minha newsletter Tech & Quality 🚀.