O analista de sistemas Carlos está desenvolvendo o software CharlieApp e implementou o teste C. O teste C consiste apenas em determinar se o método A do código de CharlieApp retorna o resultado esperado C ao chamar o método B que realiza uma consulta ao banco de dados de CharlieApp. Portanto, o teste C implementado por Carlos é de:
- A)unidade;
Errada, porque teste de unidade isola uma única unidade de código e normalmente não deveria depender de uma consulta real ao banco.
- B)aceitação;
Errada, porque teste de aceitação verifica requisitos e comportamento do sistema sob a perspectiva do usuário, não a chamada entre métodos.
- C)ponta a ponta;
Errada, porque teste ponta a ponta cobre o fluxo completo do sistema, e aqui o enunciado fala apenas de uma interação específica entre métodos.
- D)exploração;
Errada, porque teste de exploração é mais ligado à investigação manual/ad hoc de falhas, não a uma validação estruturada de chamada entre componentes.
- E)integração.
Certa, porque o teste verifica a integração entre o método A e o método B, que acessa o banco de dados, ou seja, a comunicação entre componentes reais.
Gabarito: E
Aqui a ideia central é simples: o tipo de teste depende do tamanho do pedaço do sistema que voce está exercitando e de quantas partes diferentes participam da execução. Quando o teste chama um método e, no caminho, esse método depende de outro método que faz acesso ao banco, voce já não está olhando só para uma “caixinha” isolada. Voce está verificando se duas partes do software conversam bem entre si: o método A e o método B. Isso é típico de teste de integração, porque o foco passa a ser a interação entre componentes do sistema. Em teste de unidade, voce isolaria o método A com um mock ou stub do método B, justamente para não depender do banco. Como aqui o enunciado diz que o método B realmente faz uma consulta ao banco, a execução envolve integração entre camada de código e persistência. Também não é teste de aceitação, porque esse tipo valida se o sistema atende aos requisitos do usuário, geralmente em um cenário de negócio mais amplo. E não é ponta a ponta, pois esse último normalmente percorre o fluxo completo do sistema, do início ao fim, simulando o uso real do usuário em vários componentes e camadas. Em provas, a FGV costuma cobrar essa diferença de forma bem direta: se há duas partes do sistema sendo exercitadas em conjunto, com dependência real entre elas, pense em integração. Se fosse uma única unidade isolada, com dependências simuladas, aí seria outro papo.