No Karate, como podemos trabalhar colaborativamente com a BA para automatizar cenários de negócios

Ao usar o Karate, conseguimos fazer a maioria das validações para serviços da web, conseguimos integrar com sucesso o Karate com o selenium webdriver e fazer asserções de database usando classs java. Para o DB, retornamos os conjuntos de resultados como lista, convertendo cada linha como um hashmap e o Karate como um array json. Então as validações se tornaram simples. A maioria das necessidades para nós em um lado do controle de qualidade foram alcançadas usando o Karate.

No entanto, hoje, quando introduzimos, para uma comunidade maior, um dos líderes de desenvolvimento apresentou uma pergunta. Ele é especialista em JBehave, BDD, jsonpath, java, web services etc. Também sentimos que sua pergunta é realmente relevante com base em nosso contexto. no entanto, a abordagem do Karate é diferente e pode não funcionar de acordo com o nosso conhecimento.

Em nosso contexto, precisamos fazer com que o BA escreva o BDD considerando seus cenários de negócios usando termos de negócios e o QA / Dev possa convertê-los posteriormente como scripts. (Uma abordagem que costumamos seguir usando pepino + selenium / ter certeza etc). Por exemplo, se eu tiver um arquivo de recurso e 10 cenários , as pessoas do lado comercial não entenderão os detalhes das validações vendo as etapas no karatê / ou em outra palavra o texto em inglês simples será um pouco mais autoexplicativo para elas. Precisamos dessa abordagem porque tentamos implementar mudanças no processo a partir do próprio nível da história.

Você poderia compartilhar seus pensamentos?

Resposta curta: O karatê não é para o BDD.

Eu escrevi um post no blog detalhado sobre isso aqui: Sim, Karate não é verdade BDD

Leia atentamente e compartilhe com aqueles que serão beneficiados. Sim, o Karate rouba a syntax do BDD do Pepino, mas toma uma direção diferente.

Você pode usar o Karatê nos bastidores como definições de etapa do Pepino por meio da API Java . Ou se você quiser usar algo como REST-assegurado, poder total para você .

Minha opinião pessoal é, por favor não. Você estará perdendo tempo fazendo isso:

  • Garantir que o pepino “amigo da comunidade” seja verdadeiramente “simples” e esteja no nível certo de abstração (dependendo de quem você pergunta). Esteja preparado para debates intermináveis sobre se os seus cenários de Pepino contêm detalhes de “implementação específica” ou não.
  • Na verdade, obter seus BA-s para escrever o Gherkin ou pelo menos colaborar com a equipe de desenvolvimento para escrevê-los. By the way, é essa colaboração que é o maior valor que você recebe do BDD – não a automação das especificações como testes executáveis. Então, se você pode realmente fazer isso (recebendo tempo e conhecimento Gherkin de seus BA-s), parabéns! Não muitas equipes são capazes de fazer isso.
  • É claro que o Gherkin é apenas a ponta do iceberg, você precisa escrever todas as definições das etapas. Você teria visto esta parte da documentação do Karate que descreve as diferenças entre o Karate e o Pepino .
  • Eu tenho um forte ponto de vista de que o BDD tem muito pouco (e talvez negativo) valor para testes de API. A grande diferença entre um teste de interface do usuário (face humana) versus um teste de API (voltado para a máquina) é que há um “contrato” claro para o qual você está codificando. Esse contrato é melhor expresso em termos técnicos (JSON / schema) em vez da abstração deliberada em que o BDD obriga você. O usuário final ou consumidor de uma API é tipicamente outro programador ! Sim, há uma necessidade de pensar na API como um produto – mas o BDD está levando as coisas longe demais. E especialmente quando se trata de micro-serviços, você raramente encontrará um que esteja fazendo algo mais complexo do que o simples ‘CRUD’.
  • Faça a si mesmo esta pergunta – você está esperando que seus BA-s continuem a ler o Gherkin após a fase de definição de requisitos do projeto? Tenha em mente que o BDD deve ser praticado antes que uma única linha de código seja gravada . Se o Gherkin cumpriu seu propósito de estabelecer colaboração, um entendimento compartilhado e exemplos – basta convertê-lo em testes automatizados normais e não olhar para trás!

EDIT: Olhe para o segundo exemplo aqui para ver o que acontece quando você usa pepino para testar o que deveria ser uma simples unidade ou teste de integração.

Espero que ajude 🙂

    Intereting Posts