@GustOki is attempting to deploy a commit to the BrasilAPI Team on Vercel.

A member of the Team first needs to authorize it.

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
38.6% Duplication on New Code

See analysis details on SonarQube Cloud

Olá @GustOki! Obrigado pela contribuição!

Percebi um anti-padrão no teste: o arquivo copia a implementação do handler diretamente dentro do teste:

// dentro do test file
const handler = async (req, res) => { ... } // cópia do handler real

Isso significa que o teste valida a cópia, não o handler de produção. Se o handler real em pages/api/cptec/v1/cidade/[name].js mudar, o teste continua passando sem detectar a regressão.

Para testes unitários de handlers Next.js, o correto é importar o handler real:

import handler from '@/pages/api/cptec/v1/cidade/[name]';

Porém, o projeto já tem testes E2E que cobrem esses endpoints em tests/cptec-v1.test.js. Você poderia detalhar o que esses testes unitários adicionam além da cobertura já existente? Isso ajudaria a entender se a abordagem faz sentido ou se seria melhor contribuir com o arquivo de testes E2E existente.

Olá @GustOki! Obrigado pela contribuição nos testes do CPTEC.

No entanto, o projeto utiliza testes E2E (end-to-end) que fazem chamadas HTTP reais ao servidor local, não testes unitários com mocks. Veja o padrão nos outros arquivos de teste, como tests/cpetc/previsao-v1.test.js.

Algumas observações:

• O caminho do arquivo (tests/pages/api/...) não segue o padrão do projeto (tests/{domínio}-v{n}.test.js)
• O teste copia o código do handler diretamente, o que significa que não testaria mudanças no handler real
• vi.mock é evitado — testes com mocks não detectam problemas de integração reais

Para contribuir com testes, reescreva usando E2E conforme o padrão do projeto. Qualquer dúvida, consulte o arquivo tests/cpetc/previsao-v1.test.js como referência.