Quando falamos em desenvolvimento ágil, não necessariamente queremos dizer que a vazão dos desenvolvedores será mais rápida, ou que o que foi contratado será entregue em menos tempo. É entregar com a menor incerteza possível, mais ajustado para o que o usuário precisa e com o menor esforço possível. 

É importante que nós desenvolvedores não fiquemos presos nas regras de negócio que foram definidas na concepção do produto. Software é uma coisa viva, e deve ser tratado como tal, em frequente evolução e adaptação. Então, tudo bem o desenvolvedor argumentar se algo não parece prático, ou que algum comportamento poderia ser simplificado para gerar entrega de valor mais rapidamente.

Com toda essa fluidez no desenvolvimento, o nosso objetivo sempre vai ser o feedback o mais rápido possível, para que os erros sejam minimizados a serem resolvidos no menor tempo possível, ou as mudanças de regra aconteçam sem perder o tempo do mercado, ou perder uma grande parte dos seus usuários, os quais raramente voltam a usar o sistema uma vez que saem.

Testes unitários e TDD

Quando falamos de TDD, que significa Test-Driven Development, ou Desenvolvimento Orientado por Testes, temos que falar da pirâmide de testes para entender qual tipo de testes realmente serão os mais efetivos para o desenvolvimento ágil.

Testes unitários

Na base da pirâmide estão os testes unitários. Eles são os que tomam menos tempo para desenvolver, validam apenas uma entidade, ou uma unidade (ou uma classe, como no Java), e servem para atestar como essa entidade se comporta independente das alterações futuras do sistema. Nota-se, que essas entidades ainda podem passar por mudanças que demandam atualização nos seus testes, a segurança do teste é garantir que outras entidades não afetem como a primeira funciona. Por ser os que menos tomam tempo de desenvolvimento, também são os testes que temos em maior abundância no sistema, principalmente pelo fato de que seu valor a longo prazo é maior que o das outras partes. Dentre algumas ferramentas famosas para teste unitário, podemos citar o JUnit (Java), Jest (Javascript) e RSpec (Ruby).

Testes de integração

Quando falamos de teste de integração, estamos falando sobre testes que validam uma regra de negócio que afetaria mais de uma entidade. Como uma regra de negócio de compra de produtos numa loja online, a qual depende que entidades como produtos, vendedor, comprador, carrinho, pedido e etc se comuniquem e a regra seja cumprida. Para descrever o comportamento do sistema, geralmente usamos uma ferramenta chamada Cucumber, que usa a linguagem Gherkin para descrever cenários de testes, e seus passos de execução.

Teste End-to-End

Comumente chamado de Teste de Sistema, é um teste que simula a operação de um usuário comum, geralmente com ferramentas de reprodução de comportamento. Por isso, são extremamente custosos, visto que uma simples mudança de layout, pode destruir todos os passos registrados para o sistema seguir, além de tomar mais tempo e cuidado para desenvolver. Ferramentas como Selenium são as mais usadas nesses testes, e é necessário muito cuidado para não deixar os testes frágeis a alterações.

Testes com Mock

Mock é uma palavra em inglês que no sentido de testes significa “Imitação”. Isso quer dizer que usamos uma ferramenta, no caso do java uma bastante popular que podemos citar seria o Mockito, que literalmente imita o comportamento de alguma ferramenta necessária para o nosso código, sem depender de outro sistema. Isso por que não queremos testar se a implementação funciona, e sim como o nosso sistema se comporta com a implementação, como por exemplo, uma consulta no site da FACOM para buscar as últimas notícias postadas. 

Não nos interessa se o site da FACOM está online, pois podemos confiar que ele tem a segurança de estar online sempre, e caso ele venha a sair do ar, isso afetaria nosso sistema de qualquer maneira. Não interessa nesse caso, saber como receberemos os dados da página, se tem imagens, título do artigo, etc. Para isso, podemos pegar uma página de exemplo, e anexar uma cópia do HTML da página no nosso código, ou com o uso de alguma ferramenta, como o Mockito, para gerar esse espelho de um artigo específico do site, e anexá-lo aos arquivos do nosso sistema, possibilitando que os desenvolvedores possam testar sem se preocupar com tempo de requisição, ou em casos específicos, cobranças por requisição.

Testes em sistemas legados e BDD

BDD significa, em inglês, Desenvolvimento Orientado a Comportamentos, especificamente, comportamentos que um usuário tomaria dentro do nosso software, também podendo ser chamado de Regras de Negócio.

Quando precisamos testar um sistema legado, é óbvio que não sabemos como funcionam as unidades, ou classes, do sistema, o que dificulta muito a testagem unitária, então precisamos mudar de abordagem, e ao invés disso, testar as regras de negócio que geralmente são rastreadas mais facilmente, visto que só dependem que saibamos as entradas e saídas para cada integração.

Ou seja, o nosso teste agora será um Teste de Integração, e é de suma importância que o façamos para garantir que novas funcionalidades não impactarão regras existentes, além de facilitar a depuração de bugs, principalmente por se tratar de um sistema legado.

Qualidade não é algo negociável, e um sistema de baixa qualidade diz muito sobre o time que o desenvolveu. Embora existam cargos específicos para testes manuais e automatizados End-to-End, o desenvolvedor precisa garantir que o que está sendo enviado para esses profissionais esteja cumprindo os requisitos levantados pelo P.O. e pelo cliente.

Texto por Cláudio Caramori.