Equipes frequentemente dizem que “usam automação” como se isso resolvesse a questão de como seus testes são organizados. Não resolve. Duas suítes podem ser ambas automatizadas e ainda assim serem estruturadas de maneiras completamente diferentes, com custos de manutenção também completamente diferentes. A estrutura é o *framework*, e o tipo de *framework* que você escolhe molda a velocidade com que os testes crescem, a facilidade com que não-programadores contribuem e a extensão com que uma pequena mudança na UI se propaga pelo seu código.
Este artigo aborda os seis tipos clássicos de *frameworks* de automação de testes: linear, modular, baseado em dados (*data-driven*), baseado em palavras-chave (*keyword-driven*), híbrido e baseado em comportamento (*behavior-driven*). Ele explica o que cada um é, onde se destaca e onde falha, para que você possa adequar uma estrutura à sua equipe, em vez de herdar o que o último engenheiro configurou. Os conceitos se aplicam a testes de UI, API e unitários.
O que é um framework de automação de testes
Um *framework* de automação de testes é um conjunto de diretrizes, convenções e componentes reutilizáveis que define como os testes automatizados são escritos, organizados e executados. Não é uma ferramenta que você instala. É a arquitetura dentro da qual seus testes vivem.
Um *framework* responde a perguntas estruturais antes que qualquer um escreva um teste. Onde os dados de teste residem? Como os passos reutilizáveis são compartilhados? Quem pode contribuir, apenas programadores ou também analistas? Como os resultados são relatados? Diferentes tipos de *framework* respondem a essas perguntas de maneira distinta, e é isso que os diferencia. Se você é novo na ideia geral, nossa visão geral sobre o que é teste automatizado oferece um contexto útil antes da discriminação dos tipos abaixo.
A razão pela qual isso importa é a manutenção. Escrever os primeiros cem testes automatizados é fácil. Manter mil deles enquanto a aplicação muda semanalmente é difícil, e o tipo de *framework* é o maior fator individual no custo dessa manutenção.
Considere um exemplo concreto. Uma tela de login muda os rótulos de seus campos. Em uma suíte, essa mudança quebra dois testes e leva dez minutos para corrigir. Em outra suíte testando a mesma aplicação, ela quebra duzentos testes e leva dois dias. A aplicação é idêntica; apenas a estrutura do *framework* difere. Essa lacuna é a razão pela qual o tipo de *framework* vale a pena ser pensado antes de escrever o código, e não depois.
Os seis tipos de framework
1. Linear (gravação e reprodução)
Um *framework* linear registra suas ações e as reproduz como um *script*. Cada teste é uma sequência plana de passos, sem funções compartilhadas e sem separação de dados da lógica. As ferramentas geram o *script* para você, então a barreira de entrada é quase zero.
O apelo é a velocidade para projetos pequenos, demonstrações rápidas ou uma verificação pontual (*smoke check*). O custo aparece rapidamente. Como nada é reutilizado, os mesmos passos de login são copiados e colados em cada teste. Quando a página de login muda, você edita cinquenta *scripts*. *Frameworks* lineares não escalam, e a maioria das equipes os supera em questão de semanas.
2. Modular
Um *framework* modular divide a aplicação em módulos pequenos e independentes e escreve uma função reutilizável para cada um. Um teste é então uma composição dessas funções: fazer login, pesquisar, adicionar ao carrinho, finalizar compra. Quando a tela de login muda, você corrige uma função e todos os testes se beneficiam.
Esta é a primeira estrutura que realmente escala. A desvantagem é o design inicial. Alguém precisa decidir os limites dos módulos e construir a camada de abstração antes que os testes fluam rapidamente. Para a maioria das equipes de engenharia, o modular é o padrão sensato e combina bem com a disciplina descrita em nosso guia sobre como escrever *scripts* de teste automatizados.
3. Baseado em dados (*Data-driven*)
Um *framework* baseado em dados separa a lógica de teste dos dados de teste. Uma função de teste é executada várias vezes contra linhas de entrada armazenadas em um arquivo CSV, arquivo JSON, planilha ou banco de dados. A cobertura cresce adicionando linhas, não escrevendo código.
Este tipo é ideal quando o mesmo fluxo de trabalho deve ser verificado contra dezenas de combinações de entrada: logins válidos, logins inválidos, valores de limite, variações de localidade. Para APIs especificamente, uma abordagem de teste baseada em dados com CSV e JSON transforma uma solicitação em centenas de casos. A desvantagem é que a própria lógica de teste é fixa; a estrutura baseada em dados expande as entradas, não os comportamentos.
4. Baseado em palavras-chave (*Keyword-driven*)
Um *framework* baseado em palavras-chave abstrai ações em palavras-chave nomeadas como Login, SearchProduct ou VerifyTotal. Os testes são escritos como tabelas de palavras-chave mais argumentos, frequentemente em uma planilha, para que um não-programador possa montar testes sem tocar no código.
A força é a acessibilidade. Analistas de QA e equipe de negócios podem construir e ler testes diretamente. O custo é a biblioteca de palavras-chave: engenheiros devem construir e manter a implementação por trás de cada palavra-chave, e um conjunto de palavras-chave mal projetado se torna uma carga de manutenção por si só. A estrutura baseada em palavras-chave se encaixa em equipes onde a autoria dos testes e a infraestrutura de testes são divididas entre diferentes funções.
5. Híbrido
Um *framework* híbrido combina dois ou mais dos tipos acima, mais comumente reutilização modular mais entradas baseadas em dados mais abstração por palavras-chave. É menos um tipo distinto do que o reconhecimento pragmático de que projetos reais precisam de diferentes estruturas em diferentes lugares.
A maioria das suítes de teste maduras são híbridas quando atingem alguns milhares de testes. O risco é a incoerência: se a combinação não for projetada deliberadamente, você terá o custo de manutenção de todos os tipos e a clareza de nenhum. Um *framework* híbrido funciona quando a mistura é intencional e documentada.
6. Baseado em comportamento (BDD)
Um *framework* baseado em comportamento expressa testes em linguagem quase natural usando o padrão Dado-Quando-Então (Given-When-Then), tipicamente escrito em Gherkin e executado por ferramentas como Cucumber. Um cenário é lido como uma frase: dado um usuário registrado, quando ele envia credenciais válidas, então ele acessa o painel.
O valor do BDD é o entendimento compartilhado. Produto, QA e engenharia leem a mesma especificação, o que reduz a lacuna entre o que foi solicitado e o que foi construído. O custo são duas camadas: o Gherkin legível e as definições de passo que o implementam. Se a equipe de produto nunca lê os cenários, você está pagando o custo do BDD sem colher seus benefícios. Nosso guia Gherkin para testes de API BDD mostra o padrão aplicado a APIs.
Comparando os tipos de framework
| Tipo de framework | Reutilização | Não-programadores podem criar | Custo de configuração | Escalabilidade |
|---|---|---|---|---|
| Linear | Nenhuma | Sim, via gravação | Muito baixo | Ruim |
| Modular | Alta | Não | Médio | Boa |
| Baseado em dados | Média | Parcialmente | Médio | Boa para entradas |
| Baseado em palavras-chave | Alta | Sim | Alto | Boa |
| Híbrido | Alta | Às vezes | Alto | Muito boa |
| BDD | Alta | Sim, para ler e criar | Alto | Boa |
A tabela deixa o padrão claro. Uma configuração mais barata tende a significar uma escalabilidade pior, e estruturas que incluem não-programadores exigem mais investimento de engenharia nos bastidores. Não há opção gratuita, apenas uma opção que se adapte às suas restrições.
Erros comuns de framework
Mesmo equipes que escolhem um tipo sensato frequentemente o comprometem na prática. Três erros aparecem repetidamente.
O primeiro é a abstração prematura. Uma equipe adota uma estrutura baseada em palavras-chave ou híbrida para uma suíte que tem quinze testes. A camada de abstração custa mais para construir e manter do que os testes que ela serve. A estrutura deve seguir a escala; deixe que a duplicação real justifique a próxima camada de reutilização.
O segundo é o oposto: recusar-se a evoluir. Uma suíte linear que funcionava com vinte testes ainda é linear com quatrocentos, e cada mudança na aplicação agora desencadeia uma varredura dolorosa de *scripts* copiados e colados. O custo de permanecer linear se acumula silenciosamente até que uma única pequena mudança elimine um dia de trabalho. Observe o sinal, que é editar muitos testes para uma única mudança de produto, e refatore para um modelo modular antes que a dor se torne rotina.
O terceiro é escolher um tipo para um público que ele não possui. O BDD só compensa quando não-engenheiros realmente leem o Gherkin. O *keyword-driven* só compensa quando os analistas realmente criam os testes. Se essas pessoas nunca tocam na suíte, você arca com o custo da camada extra sem nenhum benefício. Adeque o tipo a quem realmente participa, não a quem poderia em teoria.
Como escolher um tipo de framework
Escolha com base na sua equipe e projeto, não na moda.
- Tamanho e vida útil. Um *script* descartável pode ser linear. Qualquer coisa mantida por mais de um trimestre deve ser modular, no mínimo.
- Quem escreve os testes. Todos os engenheiros apontam para modular ou híbrido. Funções mistas apontam para *keyword-driven* ou BDD.
- Variedade de entradas. Muitas combinações de entrada contra fluxos de trabalho estáveis apontam para *data-driven*.
- Lacunas de comunicação. Frequentes mal-entendidos entre produto e engenharia apontam para BDD, porque a especificação compartilhada é seu principal benefício.
- Habilidades existentes. O melhor tipo de *framework* é aquele que sua equipe pode realmente manter. Uma estrutura elegante que ninguém entende falha mais rápido do que uma simples que todos entendem.
A maioria das equipes acaba com um híbrido: reutilização modular como espinha dorsal, entradas *data-driven* para casos de alta variação e BDD onde a colaboração é mais importante. Comece simples e deixe que a dor real, e não a teoria, justifique a estrutura adicional. Para estratégias de teste além do tipo de *framework*, a distinção em nosso guia cenário de teste versus caso de teste ajuda você a definir o escopo do que cada teste deve cobrir.
Onde uma plataforma ajuda
Escolher um tipo de *framework* é uma decisão de arquitetura. Executá-lo bem ainda requer as ferramentas certas. Para testes de API em particular, o Apidog oferece suporte à reutilização modular por meio de requisições compartilhadas e parametrizadas, execuções *data-driven* a partir de arquivos CSV e JSON, e um construtor de testes visual que permite a não-programadores montar testes, o que representa o espírito da estrutura *keyword-driven* sem a necessidade de uma biblioteca de palavras-chave construída manualmente.
Isso importa porque um tipo de *framework* é tão bom quanto a capacidade da equipe de segui-lo consistentemente. Uma plataforma que já incorpora a estrutura mantém os testes coerentes à medida que a suíte cresce e as pessoas entram e saem. Você pode baixar o Apidog para ver como esses padrões funcionam na prática, e então decidir quanto código de *framework* personalizado você ainda precisa. A resposta honesta é geralmente menos do que você espera, porque o Apidog já gerencia as camadas de requisição, dados e relatórios que um *framework* construído manualmente precisaria reimplementar.
Perguntas frequentes
Qual a diferença entre uma ferramenta de automação e um framework de automação de testes?
Uma ferramenta executa testes, como um *driver* de navegador ou um cliente HTTP. Um *framework* é a estrutura em torno dessas ferramentas: as convenções para organizar testes, compartilhar lógica, fornecer dados e relatar resultados. Você pode ter uma ferramenta sem um *framework*, mas os testes serão difíceis de manter. O *framework* é o que torna a automação sustentável.
Qual o melhor tipo de framework de automação de testes?
Não existe um "melhor" universal. O linear serve para *scripts* descartáveis, o modular para a maioria das equipes de engenharia, o *data-driven* para alta variedade de entradas, o *keyword-driven* e BDD para equipes com habilidades mistas, e o híbrido para suítes grandes e maduras. Adeque o tipo às habilidades da sua equipe e à vida útil do projeto, em vez de escolher a opção mais popular.
O BDD é apenas para testes de API ou apenas para testes de UI?
Nenhum dos dois. O BDD é um padrão estrutural, não uma camada. O formato Dado-Quando-Então funciona para testes unitários, de API e de UI. Seu requisito real não é a camada de teste, mas o público: o BDD só compensa quando não-engenheiros realmente leem ou escrevem os cenários.
Posso mudar os tipos de framework depois de ter construído uma suíte?
Sim, mas isso custa um esforço proporcional ao tamanho da suíte. Mudar de linear para modular significa extrair funções reutilizáveis de *scripts* copiados e colados. A lição é escolher uma estrutura que escale desde o início, pois adaptar um tipo de *framework* a milhares de testes é muito mais difícil do que começar com o certo.
Projetos pequenos precisam de um framework?
Um projeto genuinamente de curta duração pode ser executado com um *script* linear e gravado, sem um *framework* real. Mas projetos "pequenos" têm o hábito de crescer. Se uma suíte durar mais do que algumas semanas ou for manuseada por mais de uma pessoa, mesmo uma estrutura modular leve se paga rapidamente.