Fala pessoal, neste texto trago um resumo do vídeo: Acceptance Testing with Executable Specifications do Dave Farley (em inglês) em seu canal sobre Continous Delivery (que recomendo fortemente que você acompanhe) e alguns pensamentos meus a respeito do que ele disse lá. Antes de seguir com a leitura, se atenha que este resumo não substitui assistir o vídeo 😉, então não esquece de conferí-lo.
Acceptance Testing é verificar o que o software faz independentemente de como ele faz. Dave Farley descreve neste vídeo uma série de propriedades, conceitos e técnicas que nos ajudam a escrever bons testes de aceitação para o nosso software
Primeiro, as propriedades a seguir respondem a seguinte pergunta: um bom teste de aceitação:
1. Verifica se o código faz aquilo que o usuário quer;
2. Representa uma forma automatizada da "definição de pronto";
3. Verifica se o código funciona em um ambiente próximo ao de produção;
4. Testa a configuração e o deployment do código;
5. Fornece feedback antecipado;
6. É repetível e confiável.
Antes de tratar das técnicas, Dave é paciente e explica um pouco a respeito da terminologia. Neste vídeo, ele vai tratar como sinônimos BDD, ATDD (Acceptance Testing Driven Development), Specification by Example entre outros nomes. Pois ao final o objetivo é verificar se o sistema que estamos desenvolvendo é aquilo que o usuário deseja.
Portanto, chegamos à primeira definição do que seria Acceptance Testing: é uma especificação executável a respeito do comportamento do sistema. Sendo assim, é fundamental que um teste de aceite seja desacoplado de como o sistema funciona. Essa característica fundamental nasce do fato de que:
É complexo entender o que usuário precisa; logo é
Igualmente complexo desenvolver uma solução para o problema dele
Assim, ao desacoplarmos nossos testes do que o sistema faz de como ele faz, tornamos nossos testes de aceitação confiáveis. Os nossos testes são confiáveis porque como eles estão desacoplados de como o nosso sistema funciona (detalhes de implementação), podemos, sem muita dificuldade, trocar algumas características do nosso sistema, como a tecnologia que é utilizada, o ambiente em que está sendo executado, entre outras.
Mas então, como escrever os nossos testes de aceitação? Qual linguagem usar? Dave cita o livro de Eric Evans que nos apresenta de maneira estruturada o conceito de Domain Driven Design, e neste livro nos é apresentado o conceito da linguagem ubíqua. Linguagem ubíqua é a linguagem que todos os participantes do projeto usam. E essa linguagem expressa e emerge do domínio do projeto. É nesse tipo de linguagem que escrevemos nossos casos de testes.
Dito tudo isso, vamos as técnicas que Dave nos apresenta:
Capture todos os requisitos de uma perspectiva de um usuário externo do sistema
Segundo Dave, essa é uma característica fundamental deste nível de teste. Eu confio que isso decorre do fato de que o usuário final nem sempre vai ter noção de possíveis de detalhes de implementação. Logo, nos colocarmos como alguém que não conhece os detalhes de implementação, nos ajuda a escrever testes que são desacoplados desses detalhes.
Imagine trocando seu sistema por outra coisa que cumpre a mesma função. Neste caso, o teste ainda deverá fazer sentido
Essa técnica procura aplicar o conceito apresentado acima com relação ao desacoplamento: o objetivo final é que o nosso teste verifique o que o sistema faz, e não como ele faz.
Foque os testes naquilo que o usuário quer
Lembre-se: testes de aceitação são para verificar se ao final o sistema atende ao que o usuário deseja. Em decorrência disso, Dave dá a sugestão do time concordar em que cada critério de aceite seja coberto por, no mínimo, um teste de aceitação.
Imagine que uma pessoa com o menor conhecimento técnico possível esteja lendo seu caso de teste. Ainda sim, ela será capaz de entendê-lo
Particularmente acho essa técnica complexa de atingir, porém, um excelente norte na hora de criar os nossos testes de aceitação. Também é aqui que a linguagem ubíqua tem a sua vez, pois alguém sem conhecimento técnico, mas que possui conhecimento do negócio, será capaz de entender o teste de aceite e até mesmo validar se ele cumpre o que o usuário deseja.
Evite histórias demasiadamente técnicas
Ao usar a linguagem ubíqua estaremos evitando o uso de histórias que são demasiadamente técnicas e que são de difícil entendimento por todas as partes do projeto. Procure focar no comportamento do usuário e dê preferência à necessidade subjacente dele.
Torne cada requisito, especificação, história o menor possível
Foque no menor comportamento perceptível. Histórias pequenas são mais fáceis de gerenciar, estimar e desenvolver. Consequentemente tem maior chance de incluir menor risco quando liberadas para produção.
Estabeleça e use uma linguagem ubíqua
Use a criação de especificações executáveis para crescer e fortalecer essa linguagem.
Em resumo
Procure usar linguagem ubíqua na comunicação no time, na escritas das histórias e também na escrita dos testes de aceitação;
Escreva testes de aceitação que verificam o que o sistema faz e não como ele funciona.
Espero que tenha curtido o resumo. E novamente, recomendo fortemente que procure assistir o vídeo completo, pois há uma riqueza enorme de informações lá. Até a próxima.