Resumo Executivo

Maria Isabel da Costa Carvalho; Ariel da Silva Dias

Resumo elaborado pela ferramenta ResumeAI, solução de inteligência artificial desenvolvida pelo Instituto Pecege voltada à síntese e redação.

A evolução dos sistemas de software é regida por princípios que determinam a necessidade de manutenção constante para evitar a degradação da qualidade técnica e funcional. Segundo a Lei VII das Leis da evolução de software, a redução da qualidade de um código é observada conforme o mesmo cresce, a menos que ocorra uma intervenção ativa para adaptá-lo às mudanças constantes do ambiente operacional (Lehman, 1996). Nesse cenário, a implementação de metodologias que priorizem a verificação contínua torna-se um pilar fundamental para a sustentabilidade de projetos tecnológicos. O Desenvolvimento Orientado por Testes, amplamente conhecido pela sigla TDD, surge como uma das ferramentas primordiais para a manutenção da integridade do código, estabelecendo um estilo de desenvolvimento que inverte a lógica tradicional de programação ao priorizar a escrita do teste antes da funcionalidade propriamente dita (Beck, 2002).

A adoção desse estilo conscientiza o desenvolvedor sobre o que ocorre na lacuna existente entre a escrita do código e o feedback imediato após sua implementação, introduzindo técnicas rigorosas de controle sobre essa defasagem (Beck e Andres, 2004). A utilização sistemática dessa técnica é descrita como um caminho seguro para lidar antecipadamente com as incertezas e o receio inerentes ao processo de programação, colocando o profissional diante de situações complexas antes mesmo da publicação oficial do código em ambiente de produção. Esse processo resulta na entrega de feedbacks completos e reduz drasticamente a densidade de defeitos, transformando o trabalho das equipes de garantia de qualidade, ou Quality Assurance, de uma postura reativa para uma abordagem proativa, o que contribui diretamente para a redução das taxas de falha sistêmica (Bell, 2001).

Os testes de software podem ser executados de forma manual ou automatizada, sendo que a automatização é reconhecida por reduzir significativamente os custos de desenvolvimento ao economizar o tempo que seria despendido por testadores humanos em tarefas repetitivas (Oliinyk e Oleksiuk, 2019). Além do ganho de agilidade, a automação amplia a vida útil do software, uma vez que potencializa a identificação precoce e a consequente correção de erros que poderiam comprometer a operação em longo prazo (Bernardo, 2008). Existe uma diversidade considerável de testes que podem ser desenvolvidos dependendo da natureza do erro que se pretende detectar, tornando a escolha da ferramenta e do tipo de teste uma decisão estratégica para o aumento da qualidade do código. Entre as categorias principais, destacam-se os testes de unidade, testes de integração, testes de interface do usuário, testes de aceitação, testes de desempenho, testes de carga, testes de longevidade e testes de segurança (Bernardo, 2011).

A divisão clara entre esses tipos de testes permite que cada categoria utilize uma ferramenta específica e padronizada, facilitando a manutenção da aplicação e a coleta de métricas precisas, que podem variar conforme o escopo da verificação. A utilização dessas ferramentas especializadas evita que os códigos de teste interfiram diretamente na lógica de negócio da aplicação, mantendo uma separação saudável entre o código produtivo e o código de validação (Bernardo, 2011). No contexto de sistemas modernos, a interação entre componentes ocorre frequentemente por meio de protocolos de troca de informação, como o HTTP, que desempenha um papel fundamental na comunicação entre serviços em arquiteturas distribuídas. O protocolo HTTP permite a transferência de objetos na web entre servidores e clientes, oferecendo um conjunto robusto de métodos e cabeçalhos que carregam informações essenciais sobre a finalidade de cada solicitação (Fielding et al., 1997).

Considerando que a World-Wide Web utiliza esse protocolo de forma extensiva desde 1990, o desenvolvimento de ferramentas capazes de testar essa camada de comunicação tornou-se imperativo (Berners-Lee et al., 1996). Frameworks como o JUnit consolidaram-se como padrões para a criação de testes unitários em linguagem Java, enquanto o módulo Spring Test surgiu como uma alternativa integrada para aplicações construídas sobre o ecossistema Spring Boot. A robustez das interações através desses protocolos depende da execução de testes que garantam não apenas o funcionamento correto, mas também o desempenho e a confiabilidade em diferentes cenários de carga. Portanto, a escolha entre ferramentas de teste deve ser pautada em critérios técnicos que assegurem a evolução contínua do sistema sem a introdução de novas falhas ou gargalos de performance.

O detalhamento metodológico deste estudo baseia-se em um repositório desenvolvido em Java, utilizando a versão 21.0.5 2024-10-15 LTS, com a implementação do framework Spring Boot na versão 3.5.6. A infraestrutura de dados foi composta pelo sistema gerenciador de banco de dados PostgreSQL, versão 12.22, contando com um sistema rigoroso de versionamento e controle de migrações de esquema gerenciados pela ferramenta Flyway, na versão 11.13.1. O foco da investigação concentrou-se na elaboração de testes do tipo unitário, estruturados a partir de uma tabela de banco de dados denominada bed_sheet. A estrutura técnica dessa tabela foi definida com campos específicos para garantir a integridade dos dados: um identificador único do tipo BIGSERIAL atuando como chave primária, uma coluna para o tipo de produto definida como varchar não nula, um campo de preço utilizando o tipo numérico com precisão de 10 dígitos e duas casas decimais, além de campos para material e tamanho, ambos definidos como varchar e restritos a valores não nulos.

A partir dessa estrutura de dados, foram implementados no controlador da aplicação quatro endpoints fundamentais seguindo o padrão CRUD, que compreende as operações de criação, leitura, atualização e exclusão. Para a operação de criação, utilizou-se o método POST; para a leitura, o método GET; para a edição ou atualização, o método PUT; e para a remoção de registros, o método DELETE. O processo operacional de coleta de dados consistiu na criação de testes unitários para cada uma dessas requisições em dois cenários distintos e controlados. No primeiro cenário, os testes foram construídos utilizando exclusivamente o framework JUnit, com as definições contidas na classe BedSheetControllerJUnitTest. No segundo cenário, os testes foram elaborados utilizando o JUnit em conjunto com as ferramentas do módulo Spring Test, integradas na classe BedSheetControllerSpringTest.

Para garantir a precisão na comparação de performance entre as duas abordagens, utilizou-se a biblioteca Java da Apache Commons Math, em sua versão 3, que forneceu os componentes matemáticos e estatísticos necessários para a análise, incluindo a aplicação do teste T de Student para duas amostras independentes. O procedimento experimental envolveu a execução de cada teste de performance por 10 vezes consecutivas. Cada uma dessas execuções retornou o tempo médio de processamento em nanosegundos, considerando um volume de 1000 repetições para cada teste individual. O uso do teste paramétrico T de Student teve como objetivo detectar a existência de uma diferença estatisticamente real entre os tempos de execução das duas amostras, adotando-se um nível de significância rigoroso de 0,05. Esse detalhamento operacional permitiu isolar as variáveis de ambiente e focar estritamente na eficiência computacional das ferramentas de teste escolhidas.

Os resultados obtidos através das medições laboratoriais revelaram disparidades significativas entre as duas metodologias de teste aplicadas aos protocolos HTML. Ao analisar os dados brutos da classe BedSheetControllerJUnitTest, observou-se que os tempos médios de execução oscilaram entre 4962872.13 ns e 5387006.05 ns ao longo das 10 rodadas de amostragem. Em contrapartida, os testes realizados com a classe BedSheetControllerSpringTest apresentaram tempos consideravelmente superiores, variando entre 18319226.90 ns e 19475899.70 ns. A análise visual e quantitativa dos dados permitiu identificar uma diferença média constante de aproximadamente 15000000 ns de duração entre os testes realizados apenas com JUnit em comparação com aqueles que incorporaram o módulo Spring Test. Essa diferença não é meramente numérica, mas representa um impacto percentual expressivo no tempo total de integração e feedback durante o ciclo de desenvolvimento.

A aplicação do teste T de Student confirmou que essa diferença é estatisticamente significativa, uma vez que o valor de p calculado foi inferior ao nível de significância de 0,05 estabelecido na metodologia. Isso demonstra que os testes criados apenas com JUnit são inerentemente mais rápidos e, consequentemente, mais eficientes em termos de tempo de execução pura do que os testes que utilizam o Spring Test. A razão técnica para essa lentidão observada no Spring Test pode ser atribuída à complexidade das operações que o framework realiza em segundo plano. O Spring Test é responsável por validar uma série de anotações críticas, como @GetMapping, @PostMapping, @PutMapping, @DeleteMapping e @RequestBody (Spring, 2025). Além disso, a utilização da anotação @WebMvcTest exige que o framework realize o escaneamento de classes, a autoconfiguração de componentes do Model View Controller e a integração com módulos de segurança, como o Spring Security (Spring, 2025).

Todo esse processo de infraestrutura, embora necessário para garantir que o teste rode em um ambiente que simula com maior fidelidade o comportamento real de produção, torna a execução mais pesada e lenta. Por outro lado, os testes que utilizam somente o JUnit operam de forma isolada, sem criar o contexto completo do Spring. Eles executam apenas a lógica do controlador, utilizando o mínimo de dependência necessária e invocando os métodos de maneira direta, sem a necessidade de processar acessos reais aos endpoints, cabeçalhos HTTP complexos ou conversões exaustivas de JSON. Essa abordagem direta resulta em uma agilidade superior, o que é altamente benéfico em ambientes de integração contínua onde milhares de testes precisam ser executados em poucos minutos.

Entretanto, é fundamental reconhecer as implicações práticas dessa diferença de performance. Embora o JUnit puro ofereça uma velocidade superior, ele pode não capturar falhas de configuração que só apareceriam em um ambiente integrado. O presente estudo apresenta limitações por ter sido realizado com um número reduzido de endpoints, o que representa uma simplificação de uma aplicação real de grande porte. Além disso, o fato de os testes terem sido conduzidos em um ambiente controlado pode ter minimizado a interferência de fatores externos que, em uma rede real, poderiam alterar os tempos médios de resposta. A discussão desses resultados sugere que a escolha da ferramenta não deve ser baseada apenas na velocidade, mas no equilíbrio entre a rapidez do feedback e a profundidade da validação necessária para cada parte do sistema.

A comparação entre as ferramentas evidencia que o JUnit é ideal para validações de lógica de negócio pura, onde a velocidade é a prioridade máxima. Já o Spring Test, apesar de seu custo computacional mais elevado, oferece uma camada de segurança adicional ao validar a integração entre os componentes e as configurações do framework. Em cenários onde a integridade da aplicação e a verificação de aspectos de segurança, autenticação e integração com múltiplos serviços são prioritários, o investimento em tempo de execução do Spring Test justifica-se plenamente. Para pesquisas futuras, sugere-se a expansão deste estudo para ambientes distribuídos e a medição do consumo de recursos de hardware, como memória e CPU, para complementar a análise de eficiência baseada apenas no tempo de execução. A análise detalhada do consumo de memória pode revelar gargalos que o tempo de execução sozinho não é capaz de evidenciar, especialmente em arquiteturas de microsserviços onde a economia de recursos é vital.

A eficiência observada no uso do JUnit puro reforça a importância de uma pirâmide de testes bem estruturada, onde a base é composta por uma grande quantidade de testes rápidos e isolados. À medida que se sobe na pirâmide, os testes tornam-se mais lentos e complexos, como é o caso das implementações com Spring Test. A decisão técnica de qual ferramenta utilizar deve, portanto, considerar os requisitos de confiabilidade e a robustez do sistema em questão. Não existe uma ferramenta única que seja ideal para todas as situações, mas sim uma escolha adequada ao contexto específico de cada funcionalidade desenvolvida. O equilíbrio entre agilidade e segurança é o que define a maturidade de um processo de desenvolvimento de software moderno.

Conclui-se que o objetivo foi atingido, uma vez que a pesquisa demonstrou de forma quantitativa e estatística que os testes unitários realizados exclusivamente com JUnit apresentam uma performance significativamente superior, sendo cerca de três vezes mais rápidos que os testes que utilizam o módulo Spring Test. A investigação comprovou que, embora o Spring Test ofereça uma validação mais abrangente do contexto da aplicação e de suas anotações, ele introduz um overhead considerável que impacta o tempo de execução. Portanto, para desenvolvedores que buscam agilidade extrema em ciclos de feedback curto, o JUnit puro mostra-se a ferramenta mais eficiente, enquanto o Spring Test deve ser reservado para cenários onde a validação da integração e das configurações do framework é indispensável para a segurança do sistema.

Referências Bibliográficas:

Beck, K. 2002. Test-Driven Development By Example. 1ed. Addison-Wesley, Boston, MA, Estados Unidos.

Beck, K.; Andres C. 2004. Extreme Programming Explained: Embrace Change. 2ed. Addison-Wesley, Boston, MA, Estados Unidos.

Bell, J. T. 2001. Extreme programming. Thinking for Innovation, p. 1-19. Atena, Ponta Grossa, PR, Brasil. Disponível em: <https://books.google.com.br/books?hl=pt-BR&lr=&id=zNnPEAAAQBAJ&oi=fnd&pg=PR7&dq=Test+Driven+Development&ots=tVFSMEqtx6&sig=pxzVEVnsiE4-LpU3lkmBCIHfiqQ#v=onepage&q=Test%20Driven%20Development&f=true>. Acesso em: 10 out. 2024.

Bernardo, P. C. 2011. Padrões de testes automatizados. Dissertação de mestrado no Instituto de Matemática e Estatística, Universidade de São Paulo, São Paulo, SP, Brasil. Disponível em: <https://www.teses.usp.br/teses/disponiveis/45/45134/tde-02042012-120707/publichttps://pdfs.semanticscholar.org/0018/95a221312d80f69bc3c525ff458d727fd0c5.pdfo/TestesAutomatizados_PauloCheque_Dissertacao.pdf>. Acesso em: 30 out. 2024

Bernardo, P. C. 2011. Padrões de testes automatizados. Dissertação de mestrado no Instituto de Matemática e Estatística, Universidade de São Paulo, São Paulo, SP, Brasil. Disponível em: <https://www.teses.usp.br/teses/disponiveis/45/45134/tde-02042012-120707/publichttps://pdfs.semanticscholar.org/0018/95a221312d80f69bc3c525ff458d727fd0c5.pdfo/TestesAutomatizados_PauloCheque_Dissertacao.pdf>. Acesso em: 30 out. 2024

Berners-Lee, T.; Fielding, R.; Frystyk, H. 1996. Hypertext transfer protocol–HTTP/1.0. RFC 1945. Disponível em: <https://www.rfc-editor.org/rfc/rfc1945.html>. Acesso em: 30 out. 2024

Fielding, R.; Gettys, J.; Mogul, J.; Frystyk, H.; Berners-Lee, T. 1997 .Hypertext Transfer Protocol–HTTP/1.1. RFC2068. Disponível em: <https://www.rfc-editor.org/rfc/rfc2068.html>. Acesso em: 30 out. 2024

Lehman, M. M. 1996. Laws of software evolution revisited. p. 108-124. In: Software Process Technology. 1ed. Berlin, Alemanha. Disponível em: <https://www.google.com.br/books/edition/Software_Process_Technology/juGPJ-XA1dsC?hl=pt-BR&gbpv=1&dq=laws+of+software+evolution+revisited&pg=PA108&printsec=frontcover>. Acesso em: 30 out. 2024.

Oliinyk, B; Oleksiuk, V. 2019. Automation in software testing, can we automate anything we want?.p. 224-234. In: CS&SE@ SW. Disponível em: <https://ceur-ws.org/Vol-2546/paper16.pdf>. Acesso em: 30 out. 2024.

Spring. 2025. WebMvcTest (Spring Boot 3.4). Disponível em: <https://docs.spring.io/spring-boot/index.html>. Acesso em: 10 jun. 2025.

Resumo executivo oriundo de Trabalho de Conclusão de Curso da Especialização em Engenharia de Software do MBA USP/Esalq

Para saber mais sobre o curso, clique aqui e acesse a plataforma MBX Academy