DevOps ‐ Unit Test - iNineBD/Track-5Sem2025Main GitHub Wiki

📦 Documentação de Testes

Este documento descreve os testes unitários implementados para o pacote service, incluindo estrutura do projeto, bibliotecas utilizadas, explicação dos testes existentes e instruções para escrever novos testes.

👥 Responsabilidades e Boas Práticas

  • Designação de testes unitários: Os desenvolvedores responsáveis pelas tarefas que envolvem regras de negócio devem, obrigatoriamente, implementar os testes unitários referentes às funcionalidades desenvolvidas. Isso garante que quem conhece a lógica da regra seja também responsável por validá-la formalmente via testes.

  • Momento da criação dos testes: Os testes unitários devem ser implementados imediatamente após a finalização da funcionalidade, e apenas quando a regra de negócio estiver validada. Isso evita testes escritos com base em requisitos instáveis ou incorretos, além de garantir maior fidelidade entre o código testado e o comportamento esperado.

  • Responsabilidade pela integridade dos testes:

    • Quem identifica que um teste foi quebrado (por um go test ou CI/CD) deve corrigir imediatamente.
    • Quem altera uma funcionalidade que causa a quebra de testes é o responsável principal por atualizar ou reescrever os testes afetados, assegurando que o novo comportamento esteja coberto adequadamente.

  • Quais unidades serão testadas (front-end): Serão testados os componentes que estão consumindo dados e recebem dados do usuário, testando suas renderizações mockando as requisições e garantindo que estão corretas. Assim evitando erros de requisições e erros de usuários. Nos casos em que não estão sendo consumindo os dados diretamente e sim usando os props, serão mockados os dados que o propos deve receber afim de testar a renderização do componente.

  • Quais unidades serão testadas (back-end): Serão testadas as unidades fundamentais do back-end responsáveis pela lógica do negócio, garantindo que o comportamento implementado esteja de acordo com as regras definidas. Não serão testados todo e qualquer método e que retornam algo do banco, serão testados aqueles que retornam os dados das métricas, por exemplo, métodos que retornam métricas específicas de acordo com a role do usuário, validam permissões ou executam cálculos essenciais para a aplicação.

  • Como serão enviados se um teste falho no PR: Quando rodar a pipeline que irá rodar os testes e algum falhar a pessoa que abriu o PR será notificada.

  • Onde serão guardados os resultados dos testes: Os resultados dos testes serão guardados no sonar cloud para guardar o histórico.

  • Quem garantirá que está seguindo as boas práticas: A equipe.

🔁 Essa responsabilidade compartilhada fortalece a cultura de testes e promove mais confiabilidade no ciclo de desenvolvimento contínuo.

⚠️ Importante: Certifique-se de que o banco esteja ativo e populado com os dados exigidos pelos testes (usuários, projetos, papéis, etc.).

🧪 Testes Unitários com Nuxt

📚 Bibliotecas Utilizadas

Biblioteca Uso
@vue/test-utils Utilizada para montar componentes Vue em ambiente de teste
vitest Framework de testes para JavaScript/TypeScript, inspirado no Jest

🗂 Estrutura do Projeto onde estão os testes

Os testes serão colocados dentro da package de tests que terá um pasta componentes e lá irão ficar os testes das unidades que precisam ser testadas.

Exemplo:

project-root/
│
├── tests/
|   └── components
│          └── doughnut-chart.nuxt.spec.ts  # Arquivo de testes unitários
|          └── u-text.nuxt.spec.ts # Arquivo de testes unitários
│

Instalação das dependências

npm install -D vitest @vue/test-utils

✅ Testes Implementados

🔹 DoughnutChart

  • Testa o componente DoughnutChart.vue.
  • Verifica:
    • Se o título do gráfico é renderizado corretamente.
    • Se exibe a mensagem "No data" quando noData está true.

🔹 UText

  • Testa o componente UText.vue.
  • Garante que:
    • Renderiza corretamente com propriedades padrão (<p>, alinhamento à esquerda, etc.).
    • Aplica corretamente propriedades customizadas (tag, align, size, weight, color).
    • Permite classes adicionais passadas via attrs.

🛠 Como Criar um Teste Unitário em Nuxt/Vue com Vitest

Exemplo básico

import { mount } from "@vue/test-utils";
import { describe, it, expect } from "vitest";
import MeuComponente from "~/components/meu-componente.vue";

describe("MeuComponente", () => {
  it("renderiza corretamente", () => {
    const wrapper = mount(MeuComponente);
    expect(wrapper.text()).toContain("Texto esperado");
  });
});

Estrutura recomendada

  1. Use describe para agrupar testes relacionados a um componente.
  2. Dentro do describe, utilize it para cada caso de teste.
  3. Use mount() para renderizar o componente isoladamente.
  4. Use expect() para fazer asserções sobre o comportamento esperado.

🔧 Pré-Requisitos

  • Projeto configurado com Nuxt 3 e Vue 3
  • Node.js instalado
  • Dependências de testes instaladas:
npm install -D vitest @vue/test-utils

🚀 Como Executar os Testes

Rodar todos os testes:

npx vitest

Rodar em modo watch:

npx vitest --watch

Rodar testes de um arquivo específico:

npx vitest run caminho/para/componente.test.ts

🧪 Testes Unitários com Golang

📚 Bibliotecas Utilizadas

Biblioteca Uso
testing (Go padrão) Estrutura base para definição de testes (t *testing.T)
github.com/stretchr/testify/assert Biblioteca externa para asserções mais legíveis e robustas

Para instalar o testify:

go get github.com/stretchr/testify

🗂 Estrutura do Projeto onde estão os testes

Os testes serão colocados dentro da package do service que quer ser testado

Exemplo:

project-root/
│
├── service/
│   └── statisticsservice_test.go  # Arquivo de testes unitários
|   └── statisticsservice.go  # Arquivo do método
│

✅ Testes Implementados

🔹 TestGetListCardTags_AdminUser

  • Testa a função GetListCardTags para um usuário administrador (idUser = 0).
  • Verifica:
    • Se o resultado é retornado corretamente com dados válidos.
    • Se a função trata erros adequadamente quando recebe IDs inválidos.

🔹 TestGetListCardTags_OperatorUser

  • Testa GetListCardTags para um operador (idUser > 0).
  • Verifica comportamento com dados válidos e inválidos.

🔹 TestGetMetricsRole_Admin

  • Testa a função GetMetricsRole para admin.
  • Garante que:
    • Retorna http.StatusOK e resposta válida quando os dados estão corretos.
    • Retorna http.StatusBadRequest com erro no caso de IDs inexistentes.

🔹 TestGetMetrics_AdminRole

  • Testa GetMetrics com role “ADMIN”.
  • Garante retorno correto com idRole real do banco.
  • Também cobre caso com dados inválidos.

🔹 TestGetMetrics_OperatorRole

  • Testa GetMetrics com role “OPERADOR” (ou outro papel não-admin).
  • Verifica resposta correta e tratamento de erro com parâmetros inválidos.

🛠 Como Criar um Teste Unitário em Go

Exemplo básico com testing e assert

import (
    "testing"
    "github.com/stretchr/testify/assert"
)

func TestMinhaFuncao(t *testing.T) {
    // Chamada da função que será testada
    resultado, err := MinhaFuncao("entrada")

    // Verificações com assert
    assert.Nil(t, err, "Esperava erro nulo")
    assert.Equal(t, "resultado esperado", resultado)
}

Estrutura de um teste padrão

  1. Nome da função de teste: Test<NomeFuncionalidade>
  2. Inicializa os dados de entrada.
  3. Chama a função alvo.
  4. Usa assert.Nil, assert.NotNil, assert.Equal, etc., para validar.
  5. Opcional: usa t.Logf(...) para debug/log.

🔧 Pré-Requisitos

  • Go 1.18 ou superior
  • Banco de dados configurado e populado com os dados esperados
  • Módulo Go inicializado (go mod init)
  • Dependências instaladas:
go mod tidy

🚀 Como Executar os Testes

Para rodar todos os testes do projeto:

go test ./...

Para rodar apenas os testes do arquivo service_test.go:

go test ./service -v

🧪 Dicas para Expandir os Testes

  • Sempre valide casos felizes (happy path) e casos de erro.
  • Crie funções auxiliares para montar dados repetitivos (ex: props, mocks, entradas padrão).
  • Utilize testes unitários e de snapshot quando necessário para componentes visuais.
  • Use describe.each ou loops para cobrir múltiplas combinações de entrada.
  • Prefira expect() com boas mensagens ao invés de console.log() para depuração.
  • Teste acessibilidade (ex: aria-labels, foco, navegação por teclado) quando aplicável.

📌 Conclusão

Este documento serve como base para quem desejar manter ou expandir os testes do serviço. Siga o padrão estabelecido e mantenha sempre cobertura para os principais fluxos e erros possíveis.