\chapter{Testes}\label{cap:testes}

Delineadas as tecnologias e a arquitetura nos capítulos anteriores, este

capítulo se debruça como o comportamento do sistema é verificado: quais tipos

de teste existem, onde são aplicados, o que cada um é capaz --- e incapaz ---

de detectar, e por que o esforço de verificação foi distribuído da forma como

foi. O objetivo não é prescrever uma estratégia ideal, mas registrar com

honestidade o estado da prática no projeto e as suas lacunas, apresentadas de

Os dados quantitativos citados ao longo do capítulo, como o número de arquivos

de teste, referem-se ao estado do repositório em meados de outubro de 2026.

\section{Fundamentos de Teste de Software}\label{sec:tests-basic}

O aplicativo móvel, por sua vez, permanece inteiramente fora da integração

contínua: embora disponha de comandos de \textit{lint} (\texttt{expo lint})

e de verificação de tipos (\texttt{tsc --noEmit}), ambos são executados apenas

manualmente, e a suíte \textit{end-to-end} não é disparada por nenhum fluxo.

Em síntese, a verificação automatizada do Nexo cobre a superfície HTTP

e a persistência da API, a sua lógica pura e os seus trabalhadores em segundo

plano; a verificação do aplicativo móvel restringe-se a uma jornada manual de

fumaça, limitada à plataforma para a qual o produto é de fato distribuído.

podem divergir da fonte de verdade sem que nenhum teste acuse. Essas lacunas

são assumidas de forma explícita e refletem uma escolha de priorização, e não

uma garantia de ausência de defeitos. Como a própria definição de teste

antecipava, uma suíte ``verde'' demonstra apenas que os casos exercitados se

comportam como esperado.