[Dúvida] Estamos usando testes de integração da maneira correta?

Topic created · 10 Posts · 243 Visualizações
  • Pessoal, bom dia.

    Primeiro, quero deixar algumas situações antes da dúvida. x)

    Sempre vi testes de api como sendo testes de integração e aqui onde estou trabalhando (estou numa empresa em Portugal), as pessoas se referenciam a tudo como teste de integração.
    Testes de api tratam como testes de aceitação e até que faz certo sentido, porque estamos testando endpoints que deveriam ser sempre funcionais e tal.
    Agora a questão:

    As pessoas que desenvolvem o sistema (api, por exemplo), costumam desenvolver testes da api, dos endpoints com dados mockados, certo? Eu e uma colega, costumamos desenvolver praticamente os mesmos testes, mas com dados reais. O problema é: estes testes são quase iguais, a diferença é que estão mais integrados com todo o sistema e usam dados reais, dados do ambiente de QA, que é praticamente igual produção.
    Eu com meu problema existencial penso: seria bom passarmos a desenvolver apenas os testes com dados reais ja que agregam mais valor ao software. Porém, estes testes só executam contra um sistema que ainda NÃO tem o código “novo” que a ser desenvolvido, logo, a pessoa que desenvolve só terá feedback de erro quando tiver tido feito merge para QA.

    Aí é que está a situação. Alguém já passou ou passa por isso e teria alguma ideia para ajudar-me ou aconselhar-me?

    Fico muito grata,
    Ana

  • Acho que o pensamento de rodar testes em API, microserviços precisa ter um momento de execução integrado. Serviços podem consumir outros serviços, ou chamar outros ambientes e trabalhar somente com integrados pode gerar erros aleatorios os quais não estão ao seu controle para resolver.
    Eu acho que uma estrutura de testes mais sólida, seria uma solução para “andar” por ambientes. Ao efetuar o deploy, por ambiente, se executa os testes e assim já tem um feedback de problema ou não.
    O que me pareceu é que se está tendo esforço duplicado testes de um lado, já mockados e uma replica dos mesmos , mas dai apontando para ambientes e executando. Acho que equalizar isso pode ser um caminho para ver alguma luz na estrageia a tomar (Se o ambiente e a equipe ajudam para isso acontecer…claro…)

  • Se vocês estão fazendo testes ‘iguais’ alguem ta fazendo ta meio torto nesse role… … seja o desenveolvedor testando return de mock (!!!), seja vcs fazendo teste de integração que se limita a uma chamada só.

    Se vocês não tem um ambiente novo para rodar esse monstrinho… dai fica mais dificil ainda…

  • Oi Ana!!!

    Saudades de ti, guria!!! 😃

    Aqui a gente, QA, não realiza testes de endpoint especificamente. Realizamos os testes de negócio que fluem a navegação por vários endpoints.
    Inclusive realizamos testes híbridos, enviando um request via webdriver e checar algum dado via API, e o contrário… popular dados via endpoint e navegar pela aplicação checando se o sistema se comporta como o esperado. Isto dá muita liberdade e permite testar fluxos complexos que são mais difíceis realizar se forem feitos tudo em tela OU tudo via API.

    Lembrando que, o pipeline de testes deve ser pensado no processo do time…
    Exemplo, ter um feedback de testes de API do tipo smoke, ou seja, só checar o funcionamento do endpoint com mock, deve ter o objetivo de ter um feedback rápido para o desenvolvedor. Enquanto os testes de "negócioˆpodem rolar ao promover uma nova versão (checando back + front) para um ambiente de QA, ou Staging, por exemplo.

    Então daí cada nível de testes vai cumprir o seu propósito!
    Como o @Leonardo-Galani e o @Ramses-Saccol-de-Almeida disseram… o time precisa estar bem ciente de qual o objetivo da existência de cada nível de testes, onde eles executam e o que visa garantir. 😃

    Bjos!
    Bárbara Cabral

  • Olá, gente. Desculpem a demora.

    Então, coisas que vocês falaram e sim, são boas estratégias e que já estamos no processo de tornar real, é o fato de “andar” uma pipeline com testes end-to-end da nossa principal feature e assim conseguimos testar vários serviços ao mesmo tempo. E sobre o fato de estarmos fazendo testes de aceitação dos endpoints com mocks (aqui feito por devs) e o fato de fazermos tambem com dados reais, nós ainda vamos discutir em cluster aqui na empresa pra pensarmos numa melhor estratégia.

    Um colega perguntou se conserguiríamos testar localmente os serviços “reais”. Conseguimos, porém com um ambiente de staging que geralmente não funciona perfeito como QA e pode vir a causar flakys nas pipelines. Então, se formos continuar com os testes integrados com dados reais e batendo nos serviços, podemos diminuir a quantidade de testes que temos e criar mais casos end-to-end também. Não consigo entrar muito em detalhe aqui porque entraria muito no negócio da empresa.

    Enfim, muito obrigada pela ajuda pessoal. Bom poder contar com essa comunidade 🙂

    PS.: Quanto tempo, Barbara! haha

  • Olha @Ana-Paula-Vale … temos esse problema de ambiente de teste FLAKY . onde muita gente usa a cada 1hora tem deploy de branch xyz em servico yzf … e tem uma equipe correndo para montar containers desses serviços para subir de forma isolada para rodar os testes… para os sistemas um pouco mais simple sem muitas dependencias isso já esta feito e esta funcionando muito bem… os testes não são mais feitos em staging… e sim nesse container com a ultima versão / tag de todos os serviços.

  • @Ana-Paula-Vale O quanto for possível deixar isolado, (sem pensar em mocks, mas sem concorrencia de ambiente…No caso containers) Melhor para analisar problemas. Isso seria o “testar localmente”.
    Sobre testes flaky. Se conseguir rodar eles isolado, existe a possibilidade de isolar o que é problema do teste, com problema de ambiente. E com isso reduzir um pouco onde atacar os problemas.

  • Se entendi bem, a ideia de vocês, seria criar um novo ambiente com dados reais e só para os testes, certo?

  • tl:dr da minha parte -> “dockerizar” os apps e serviços, subir via compose ou similar para ter um ambiente ‘local’ estavel .

  • Entendi 🙂