Executando verificação de segurança...
2

🚨 VOCÊ JÁ ENTREGOU UMA TAREFA BUGADA PORQUE ESQUECEU DE ALGUNS CASOS DE USO? 🚨

Ao longo dos meus 8️⃣ anos no desenvolvimento de software, enfrentei um desafio recorrente: tarefas mal especificadas. 😰

Quantas vezes os casos de uso foram negligenciados pelo PO? E se, durante o desenvolvimento, esquecesse de um detalhe crucial? 🤔 Estes erros muitas vezes só eram percebidos durante os testes ou, pior, quando os usuários começavam a interagir com a aplicação. 😓

Este cenário começou a mudar para melhor quando tive a sorte de trabalhar com um PO que usava Gherkin para especificações. 🌟 A partir desse momento, a responsabilidade de definir os casos de uso foi compartilhada entre o PO e eu. Essa mudança não só facilitou a introdução de testes automatizados, mas também me ajudou a entregar um software mais livre de bugs. 🛠️💡

Vamos a um exemplo prático. 🧐

Imagine que você recebeu a seguinte User Story:

Como usuário, devo poder resgatar um cupom de desconto no final da compra. 🛍️

Traduzindo essa User Story para testes automatizados no Jest:

describe('Resgate de cupom baseado na User Story', () => {
  it('deve permitir que os usuários resgatem um cupom de desconto', () => {
    // Simular processo de checkout
    // Inserir código do cupom
    expect(valorFinal).serDescontado();
  });
});

No entanto, este teste parece bastante geral e falta detalhe.

Agora, vejamos como o Gherkin pode refinar isso: 👇

Cenário: Resgatando um cupom válido
Dado que o usuário está finalizando uma compra
Quando ele insere um código de cupom válido
Então o desconto apropriado deve ser aplicado ao total 🟢

Cenário: Resgatando um cupom expirado
Dado que o usuário está finalizando uma compra
Quando ele insere um código de cupom expirado
Então nenhum desconto deve ser aplicado
E uma mensagem informando que o cupom expirou deve ser exibida. 🔴

Traduzindo os cenários Gherkin refinados para testes no Jest:

describe('Resgate de cupom baseado no Gherkin', () => {
  it('deve aplicar desconto para cupom válido', () => {
    // Simular processo de checkout
    // Inserir código de cupom válido
    expect(valorFinal).serDescontado();
  });

  it('deve mostrar erro para cupom expirado', () => {
    // Simular processo de checkout
    // Inserir código de cupom expirado
    expect(valorFinal).not.serDescontado();
    expect(mensagemDeErro).toBeCalledWith('Cupom expirado');
  });
});

As especificações Gherkin não apenas abordam o cenário de um cupom válido, mas também consideram a situação de um cupom expirado, que poderia facilmente ser esquecido com uma User Story mais vaga.

Carregando publicação patrocinada...
1

boa! como analista de negócios tenho tambem o costume de escrever os critérios de aceite como Given/When/Then, facilita muito para ilustrar os comportamentos esperados!

como desenvolvedor, deve ter espaço dentro do time para levantar a mão e levar uma sugestão de critério de aceite para o PO/BA, as vezes algo passa batido ou acaba aparecendo quando se está mexendo no código.

1