Introdução aos Testes Automatizados de Software com JavaScript

Os Testes Automatizados de Software do Fluxo de Exceção são um tipo de teste de software que foca em validar como o sistema se comporta diante de cenários inesperados ou condições de erro. Em vez de testar apenas os caminhos ideais (também chamados de fluxos de sucesso), esses testes garantem que o sistema consiga lidar corretamente com situações de falha ou exceção, como entradas inválidas, indisponibilidade de recursos ou erros de lógica.

Para forçarmos um erro, podemos duplicar o mesmo teste, e definir um produto como null, por exemplo.

// Teste do fluxo de exceção

try {
  const produto = null;
  const compra = new Compra();
  compra.setProduto = produto;

  if (compra.produto === produto) {
    console.log("O setProduto funcionou.");
  } else {
    console.log("O setProduto não funcionou.");
  }
} catch (erro) {
  if (erro.message === "Produto inválido") {
    console.log("O setProduto retornou o erro esperado.");
  } else {
    console.log("O setProduto não retornou o erro esperado.");
  }
}

// Output: O setProduto funcionou.

Nesse caso, porém, o output ainda mostra que o compra.setProduto funcionou. O nosso teste está indicando que existe um problema na nossa classe, o setter não retornou o erro que esperávamos. 

Isso acontece porque realmente ainda não colocamos essa validação na nossa classe. Ela deve ser assim:

class Compra {
  set setProduto (produto) {
    if (!produto) {
      throw new Error("Produto Inválido");
    }

    this.produto = produto;
  }
  
  set setValor (valor) {
    this.valor = valor;
  }
  
  set setDesconto (desconto) {
    this.desconto = desconto;
  }
  
  finalizar () {
    return `Compra do produto XYZ finalizada no valor de 30 reais.`;
  }
}

Agora, sim, se rodarmos novamente o teste, o output deve ser como esperamos:

// Teste do fluxo de exceção

try {
  const produto = null;
  const compra = new Compra();
  compra.setProduto = produto;

  if (compra.produto === produto) {
    console.log("O setProduto funcionou.");
  } else {
    console.log("O setProduto não funcionou.");
  }
} catch (erro) {
  if (erro.message === "Produto inválido") {
    console.log("O setProduto retornou o erro esperado.");
  } else {
    console.log("O setProduto não retornou o erro esperado.");
  }
}

// Output: O setProduto retornou o erro esperado.

A implementação da classe para atender totalmente os requisitos, poderia ficar da seguinte maneira:

class Compra {
  set setProduto (produto) {
    if (!produto) {
      throw new Error("Produto inválido");
    }
    
    this.produto = produto;
  }
  
  set setValor (valor) {
    if (!valor || valor <= 0) {
      throw new Error("Valor inválido");
    }
    
    this.valor = valor;
  }
  
  set setDesconto (desconto) {
    if (desconto > this.valor) {
      throw new Error("Desconto inválido");
    }
    
    this.desconto = desconto;
  }
  
  finalizar () {
    const valorFinal = this.valor - this.desconto;
    
    return `Compra do produto ${this.produto} finalizada no valor de ${valorFinal} reais.`;
  }
}

Testes Automatizados x Bugs

E, se por engano, alterássemos o código da nossa classe, e isso levasse a um bug? É aqui que entra o poder dos testes automatizados de software. Com eles, conseguimos identificar comportamentos do sistema que não esperávamos que tivessem tal resultado. Vamos a um breve exemplo, vou comentar todo o código interno do setter setProduto, que ficará da seguinte forma:

class Compra {
  set setProduto (produto) {
    /* if (!produto) {
      throw new Error("Produto inválido");
    }
    
    this.produto = produto; */
  }
  
  set setValor (valor) {
    if (!valor || valor <= 0) {
      throw new Error("Valor inválido");
    }
    
    this.valor = valor;
  }
  
  set setDesconto (desconto) {
    if (desconto > this.valor) {
      throw new Error("Desconto inválido");
    }
    
    this.desconto = desconto;
  }
  
  finalizar () {
    const valorFinal = this.valor - this.desconto;
    
    return `Compra do produto ${this.produto} finalizada no valor de ${valorFinal} reais.`;
  }
}

Com isso, se rodarmos novamente o primeiro teste que criamos, ele passará a ter um output diferente do esperado:

// Teste do fluxo de sucesso

try {
  const produto = "Camiseta";
  const compra = new Compra();
  compra.setProduto = produto;

  if (compra.produto === produto) {
    console.log("O setProduto funcionou.");
  } else {
    console.log("O setProduto não funcionou.");
  }
} catch (erro) {
  if (erro.message === "Produto inválido") {
    console.log("O setProduto retornou o erro esperado.");
  } else {
    console.log("O setProduto não retornou o erro esperado.");
  }
}

// Output: O setProduto não funcionou.

Assim, o teste cumpriu o seu papel, ao testar o setter da classe que criamos e nos indicar que algo foi modificado no código que fez com que ocorresse um erro e o comportamento tivesse um resultado não esperado.

Aqui, conseguimos compreender o papel de um teste automatizado. Claro que nesse caso, é um exemplo bem simples, mas em sistemas grandes e complexos, é possível termos testes que validam cada parte do software e nos indicam se alguma alteração que realizamos levou ao aparecimento de bugs, o que nos dá maior tranquilidade durante o desenvolvimento.

Se você está interessado em se aprofundar ainda mais nos testes automatizados de software e tirar dúvidas sobre a implementação de diferentes cenários, como fluxos de exceção, o Fórum da Casa do Desenvolvedor é um ótimo espaço para trocar experiências e obter ajuda da comunidade de desenvolvedores. Lá, você pode discutir questões sobre testes de software e compartilhar desafios e soluções com outros profissionais da área.