Melhores praticar para escrever testes de API

Topic created · 5 Posts · 85 Visualizações
  • Atualmente estou automatizando testes de API e me surgiu algumas dúvidas sobre “melhores praticas”.

    1. Ao descrever os testes, vocês preferem validar a resposta do request criando múltiplos blocos de teste (it) ou preferem validar toda a resposta do request em um único bloco de teste?

    múltiplos blocos de teste (it)

    let res;
    
    const randomAccount = {
      'email': '[email protected]',
      'password': '123456',
    };
    
    describe('Create accounts with email and password', function() {
      describe('should create a valid account', function() {
        before(function() {
          return accountsHelper.createNewAccount(randomAccount)
            .then(function(response) {
              res = response;
            });
        });
    
        it('should return status code 200', function(done) {
          expect(res.status).to.equal(commonData.statusCode.ok);
          done();
        });
    
        it('should return response', function(done) {
          expect(res.body.admin).to.equal(false);
          done();
        });
    
        after(function() {
          return accountsHelper.deleteAccount();
        });
      });
    });
    

    em um único bloco de teste (it)

    let res;
    
    const randomAccount = {
      'email': '[email protected]',
      'password': '123456',
    };
    
    describe('Create accounts with email and password', function() {
        it('should create a valid account', function() {
          return accountsHelper.createNewAccount(randomAccount)
            .then(function(res) {
              expect(res.status).to.equal(commonData.statusCode.ok);
              expect(res.body.admin).to.equal(false);
            });
        });
    
        after(function() {
          return accountsHelper.deleteAccount();
        });
    });
    

    Múltiplos blocos de teste (it)

    Vantagens - No report, fica mais legível para quem está lendo os testes saber o que falhou exatamente: se foi o status code, se foi a resposta ou até mesmo se uma propriedade deveria retornar number mas retornou string, pois esses testes estarão escritos separadamente
    Desvantagens - fica dependente do before hook para receber a resposta

    Em um único bloco de teste (it)

    Desvantagens - quando o teste falha, não fica muito legível se falhou o status, a resposta ou o tipo de dado, pois todo o teste estará em um único bloco

    Pois então, como vocês estão fazendo? O que sugerem? Algum material a respeito desse assunto?

  • Unico bloco. Pois dentro de um arquivo de testes tu pode ter mais cenarios…Fora que a desvantagem que comentou, pode ser muito bem tratada para retornar o response completo e asserção e ao “printar” isso tu analisa ambos.

  • @Ramses-Saccol-de-Almeida Obrigado pela resposta. E quanto a scenarios bem mais complexos dos que eu mencionei acima? Por exemplo, um cenário que precise executar uns 4 passos antes de realmente testar o cenário X, ficaria legível colocar isso dentro de somente um bloco it?

  • @Rafa Ai é preciso entender “aonde quer chegar”…se tu tem passos a serem feitos antes do teste, esse passos não são os teste…são pré requisitos…Se esses passos precisam ser validados, ai é preciso entender que tipo de teste está tentando fazer…(poderia jogar em blocos de it, mas ainda assim é preciso entender que cenário está cobrindo)

  • atualmente eu crio contextos onde X cenários tem o mesmo ‘setup’… para evitar copy paste the setup para um cenários… e dentro desse cenário… eu faço as chamadas que eu preciso… e não importa se é 5 ou 10… se é exclusiva daquele cenário, e vc nao duplica codigo, é de boa.