REGISTRO DOI: 10.69849/revistaft/dt10202511141820
Gustavo Minghini Gaspar¹
Renata Mirella Farina²
RESUMO
O Desenvolvimento Guiado por Testes (Test-Driven Development – TDD) é uma prática consolidada nas metodologias ágeis, baseada na criação de testes automatizados antes da implementação do código. Este trabalho tem como objetivo analisar a aplicabilidade do TDD por meio de uma prova de conceito (PoC), evidenciando seus princípios, etapas, benefícios e limitações. A metodologia consistiu na implementação prática de uma funcionalidade simples utilizando o ciclo Red–Green–Refactor, com registro das etapas executadas. A revisão bibliográfica, aliada à PoC, demonstrou que o TDD contribui para a melhoria da qualidade e modularidade do código, redução de falhas, aumento da confiabilidade e fortalecimento de uma cultura voltada à qualidade no desenvolvimento de software. Entretanto, foram observados desafios como a curva de aprendizado, o esforço inicial e a necessidade de suporte organizacional. Conclui-se que, quando aplicado de forma disciplinada e associado a outras práticas ágeis, o TDD representa uma estratégia eficaz para promover a sustentabilidade e robustez do software.
Palavras-chave: Test-Driven Development; Qualidade de Software; Metodologias Ágeis; Engenharia de Software.
ABSTRACT
Test-Driven Development (TDD) is a consolidated practice within agile methodologies, based on creating automated tests prior to code implementation. This study aims to analyze the applicability of TDD through a proof of concept (PoC), highlighting its principles, stages, benefits, and limitations. The methodology consisted of implementing a simple functionality using the Red–Green–Refactor cycle, with evidence recorded at each stage. The literature review, combined with the PoC, demonstrated that TDD enhances code quality and modularity, reduces defects, increases reliability, and reinforces a quality-oriented development culture. However, challenges such as the learning curve, initial effort, and the need for organizational support were identified. It is concluded that, when applied in a disciplined manner and combined with other agile practices, TDD is an effective strategy for promoting software robustness and sustainability.
Keywords: Test-Driven Development; Software Quality; Agile Methodologies; Software Engineering.
1. INTRODUÇÃO
O desenvolvimento de software moderno demanda soluções capazes de garantir qualidade, confiabilidade e capacidade de adaptação em ambientes dinâmicos. Nesse cenário, as metodologias ágeis consolidaram-se como abordagens eficientes para enfrentar a complexidade crescente dos sistemas. Entre essas práticas, destaca-se o Test-Driven Development (TDD), técnica que propõe a criação de testes automatizados antes da implementação do código, estabelecendo um ciclo sistemático de construção e validação contínua (BECK, 2003).
O TDD foi popularizado dentro do Extreme Programming (XP) e tem sido amplamente estudado tanto no meio acadêmico quanto industrial. Evidências apontam que a prática contribui para a redução de defeitos, maior modularidade do código, facilidade de manutenção e maior confiança no processo de desenvolvimento (FOWLER, 1999; RAHMAN et al., 2024). Pesquisas recentes também indicam uma evolução no uso do TDD por meio de recursos baseados em inteligência artificial, que podem apoiar desenvolvedores iniciantes e aprimorar a eficiência do processo (PENG et al., 2023).
Além disso, estudos longitudinais mostram que os benefícios do TDD tendem a ser percebidos com maior clareza em médio e longo prazo, reforçando sua importância como prática disciplinada de engenharia de software (FUCCI et al., 2018). Contudo, sua adoção ainda enfrenta desafios, incluindo curva de aprendizado, custo inicial de implementação e resistência cultural de equipes habituadas a métodos tradicionais, o que exige capacitação e maturidade organizacional.
Diante desse contexto, o objetivo deste trabalho é analisar o Test-Driven Development e avaliar sua aplicabilidade por meio de uma prova de conceito, discutindo seus princípios, etapas, vantagens, limitações e evidências práticas recentes, a fim de compreender seu papel na melhoria da qualidade do software.
O problema de pesquisa que orienta este estudo é: a aplicação de uma prova de conceito pode demonstrar a viabilidade e os benefícios do TDD como estratégia para melhoria da qualidade e produtividade no desenvolvimento de software?
Parte-se da hipótese de que uma prova de conceito baseada em TDD é capaz de demonstrar ganhos significativos na qualidade do código e confiabilidade do software, embora seus efeitos sobre a produtividade possam variar conforme a experiência da equipe e o contexto do projeto.
Para este estudo, foi conduzida uma prova de conceito com o propósito de demonstrar a aplicação prática do TDD. A PoC consistiu na implementação de uma funcionalidade simples utilizando o ciclo Red–Green–Refactor, com a criação de testes automatizados antes da codificação e posterior refatoração do código. Durante o processo, foram registrados prints de tela como evidência das etapas executadas e da validação contínua do código conforme a abordagem proposta pelo TDD.
2. REVISÃO BIBLIOGRÁFICA
A revisão bibliográfica tem como objetivo apresentar os principais fundamentos teóricos relacionados ao Desenvolvimento Guiado por Testes (TDD), destacando sua evolução, princípios e utilização no desenvolvimento de software. São exploradas contribuições clássicas e pesquisas recentes que analisam os efeitos da técnica na qualidade do código, manutenção, produtividade e estruturação de sistemas. Também são abordadas abordagens relacionadas, como Behavior-Driven Development (BDD) e Acceptance Test-Driven Development (ATDD), evidenciando semelhanças, diferenças e complementaridades. Com esse referencial, busca-se construir uma base sólida para compreender os benefícios, desafios e limitações do TDD, apoiando a análise apresentada no decorrer do trabalho.
2.1 TDD e o Aumento da Qualidade e Produtividade
O TDD é uma abordagem ágil consolidada que se baseia no ciclo vermelho-verde refatorar, no qual o desenvolvedor escreve inicialmente um teste automatizado, implementa o código mínimo necessário para fazê-lo passar e, em seguida, realiza a refatoração para melhorar sua qualidade interna sem alterar a funcionalidade externa (BECK, 2003). Esse processo estimula uma forma disciplinada de desenvolvimento, na qual cada incremento é acompanhado por validação imediata, reduzindo a probabilidade de introdução de erros ao longo do ciclo de vida do software.
Além de favorecer modularidade e manutenibilidade, o TDD influencia diretamente o design do sistema, uma vez que a escrita prévia de testes conduz os desenvolvedores a estruturarem o código de maneira mais clara e desacoplada (FOWLER, 1999). Esse aspecto torna-se particularmente importante em projetos de grande porte, nos quais a escalabilidade e a capacidade de evolução contínua são requisitos fundamentais.
Estudos demonstram que a prática contribui para a redução de defeitos e retrabalho, permitindo que falhas sejam identificadas e corrigidas ainda nas fases iniciais de desenvolvimento (GEORGE; WILLIAMS, 2004; NAGAPPAN et al., 2008). Pesquisas recentes reforçam que equipes que adotam o TDD relatam ganhos em clareza arquitetural, maior estabilidade do código e menor incidência de erros em ambientes de produção, indicando que a técnica atua como fator preventivo de qualidade (RAHMAN et al., 2024).
Outro ponto de destaque é a sua função como documentação viva. Ao descrever de forma explícita o comportamento esperado do sistema, os testes automatizados tornam-se não apenas ferramentas de verificação, mas também instrumentos de comunicação dentro da equipe. Esse recurso facilita o alinhamento entre desenvolvedores, acelera o processo de integração de novos membros e reduz ambiguidades na interpretação dos requisitos (MARTIN, 2008).
2.2 Comparações com Outras Abordagens
Embora o TDD seja amplamente reconhecido e aplicado na engenharia de software, outras práticas surgiram como variações ou complementos, entre elas o Behavior-Driven Development (BDD) e o Acceptance Test-Driven Development (ATDD). O BDD diferencia-se do TDD ao priorizar a especificação do comportamento do sistema em linguagem natural, utilizando formatos compreensíveis tanto para desenvolvedores quanto para testadores e clientes. Essa característica amplia a colaboração entre os envolvidos no projeto e favorece o alinhamento entre requisitos técnicos e objetivos de negócio. Enquanto o TDD foca na lógica interna do código e na validação em nível de unidade, o BDD orienta-se pela perspectiva do usuário final, assegurando que o software atenda às expectativas funcionais e às necessidades do cliente (NORTH, 2006).
O ATDD, por sua vez, concentra-se na definição de testes de aceitação antes do início da implementação. Esses testes, elaborados em conjunto com o cliente, funcionam como critérios objetivos de validação de requisitos de negócio. Diferentemente do TDD, que atua em nível técnico, o ATDD direciona-se ao nível de aceitação do sistema, buscando confirmar se a entrega realmente agrega valor ao usuário final (RAHMAN et al., 2024).
Revisões sistemáticas indicam que TDD, BDD e ATDD não devem ser interpretados como abordagens concorrentes, mas como estratégias complementares que podem ser combinadas em um mesmo processo de desenvolvimento. A aplicação conjunta possibilita equilibrar diferentes dimensões do software: robustez do código, clareza dos requisitos e validação de valor de negócio. A escolha da prática mais adequada, ou da combinação entre elas, depende diretamente do contexto organizacional, da maturidade técnica da equipe e dos objetivos estratégicos do projeto (MUNIR; MOAYYED; PETERSEN, 2014).
2.3 Evidências Recentes na Indústria e Academia
Estudos recentes têm aprofundado a análise do TDD em diferentes contextos, trazendo evidências tanto em cenários industriais quanto acadêmicos. Na indústria, Uyaguari et al. (2022), em revisão sistemática, destacaram que o TDD apresenta resultados consistentes na melhoria da qualidade externa do software, sobretudo pela redução de defeitos e maior confiabilidade em produção. Entretanto, os autores ressaltam que sua eficácia em termos de produtividade é menos uniforme, variando de acordo com fatores como maturidade da equipe, complexidade do sistema e suporte organizacional.
No meio acadêmico, Fucci et al. (2018) realizaram um estudo longitudinal com estudantes de computação e observaram que o TDD aumenta a produção e a retenção de testes ao longo do tempo, contribuindo para a consolidação da prática entre iniciantes. Contudo, os resultados não indicaram ganhos imediatos em produtividade, sugerindo que os benefícios da técnica podem se manifestar de forma mais clara apenas em horizontes de médio e longo prazo.
A incorporação de Inteligência Artificial ao processo também tem sido alvo de investigações recentes. Peng et al. (2023) analisaram o uso de ferramentas de apoio baseadas em IA no contexto do TDD e concluíram que a prática pode auxiliar desenvolvedores menos experientes, tornando o processo de escrita de testes mais eficiente. Apesar disso, os autores alertam que essa abordagem ainda exige maior esforço na etapa de refatoração, a fim de garantir que a qualidade do código seja mantida ao longo do tempo.
Outro aspecto importante refere-se a projetos críticos ou de maior impacto, nos quais fatores organizacionais desempenham papel decisivo para a adoção da prática. Santos e Goldman (2018) observaram que a efetividade do TDD em ambientes acadêmicos e industriais está diretamente relacionada à disponibilidade de treinamento e suporte institucional. Sem esses elementos, a implementação tende a ser parcial ou insustentável, limitando os benefícios esperados.
3. DESENVOLVIMENTO
Esta seção apresenta o desenvolvimento conceitual do Trabalho, detalhando os princípios fundamentais que orientam o Test-Driven Development e as etapas que compõem seu ciclo de implementação. Também são descritas as principais vantagens associadas à prática, assim como desafios e limitações identificados tanto na indústria quanto na academia. O objetivo é aprofundar a compreensão da técnica, demonstrando como ela atua na melhoria da qualidade do software, na redução de falhas e no aumento da confiabilidade, ao mesmo tempo em que evidencia fatores que podem influenciar sua adoção e eficácia no contexto real de desenvolvimento.
3.1 Princípios fundamentais do TDD
O TDD é estruturado em três princípios fundamentais: escrever o teste antes do código, observar sua falha inicial e, em seguida, implementar a solução mínima necessária para que o teste seja aprovado. Esses princípios estão sintetizados no ciclo vermelho-verde-refatorar: o estado vermelho indica a falha de um teste ainda não suportado pelo sistema; o estado verde corresponde à escrita do código que permite ao teste ser bem-sucedido; e a etapa de refatoração refere-se ao aprimoramento contínuo do código, sem alteração de sua funcionalidade externa (BECK, 2003).
Na fase inicial, o desenvolvedor formula um teste que descreve de forma objetiva a funcionalidade ou a melhoria desejada. Como essa funcionalidade ainda não foi implementada, o teste falha, estabelecendo o ponto de partida para o desenvolvimento. Em seguida, é escrita a solução mais simples possível para que o teste seja validado, priorizando clareza e funcionalidade mínima (AMBLER, 2004). Após a aprovação do teste, inicia-se a etapa de refatoração, em que o código é revisado e aprimorado quanto à legibilidade, modularidade e eficiência, assegurando uma base sustentável para futuras evoluções (FOWLER, 1999).
Esse ciclo, embora aparentemente simples, desempenha papel essencial no processo de desenvolvimento, pois garante que cada incremento seja acompanhado de validação imediata. Mais do que uma técnica de programação, o TDD configura-se como um mecanismo de controle de qualidade contínuo, incentivando o desenvolvedor a refletir sobre design, clareza e robustez do código a cada iteração. Como observa Koskela (2008), a aplicação disciplinada desse processo promove soluções mais consistentes, modulares e menos suscetíveis a falhas, consolidando-se como um dos pilares das metodologias ágeis modernas.
Adicionalmente, a prática reforça a importância de uma mentalidade voltada à prevenção de defeitos, em vez da simples correção posterior. Estudos de caso evidenciam que o TDD pode reduzir significativamente a densidade de falhas em comparação com abordagens tradicionais, atuando como estratégia proativa de qualidade. Essa inversão de paradigma contribui para diminuir custos de manutenção, estimular o pensamento incremental e favorecer a criação de sistemas mais confiáveis. Em equipes maiores ou distribuídas, o ciclo também funciona como recurso de comunicação implícita, já que os testes documentam de forma clara o comportamento esperado do sistema, auxiliando tanto na integração de novos membros quanto na continuidade do projeto (MARABESI et al., 2024).
3.2 Etapas do TDD
O ciclo de desenvolvimento do TDD é estruturado pelas etapas Red–Green–Refactor, que orientam o processo de desenvolvimento de forma incremental e organizada. A etapa Red corresponde à criação de um teste automatizado que descreve uma nova funcionalidade ou melhoria desejada. Nesse momento, como o código responsável por atender ao teste ainda não foi implementado, o resultado esperado é a falha inicial, que serve como referência para o início da codificação. Conforme ilustrado nas Figuras 1 e 2, essa fase estabelece propositalmente um cenário de teste mal sucedido, definindo o ponto de partida para a construção da solução.
Figura 1 – Etapa Red do ciclo TDD
Figura 2 – Etapa Red do ciclo TDD (continuação)
Na etapa Green, o desenvolvedor implementa o código mínimo necessário para que o teste seja aprovado. Nesse momento, o foco não está em construir uma solução final ou otimizada, mas sim em atender ao comportamento esperado da forma mais simples e direta possível, garantindo um avanço seguro e incremental no desenvolvimento. Essa fase pode ser observada nas Figuras 3 e 4, que ilustram a aprovação do teste após a implementação do código básico (ASTELS, 2003).
Figura 3 – Etapa Green do ciclo TDD
Figura 4 – Etapa Green do ciclo TDD (continuação)
A etapa Refactor ocorre após o código atender aos requisitos do teste. Nesse momento, ele é aprimorado em sua estrutura interna, buscando maior clareza, organização e eficiência, sem alterar o comportamento já validado. Esse processo contínuo de refatoração contribui para um código mais limpo, menos redundante e mais sustentável ao longo do tempo, facilitando manutenções e evoluções futuras (FOWLER, 1999). A aplicação dessa etapa, que envolve a melhoria da estrutura do código após a validação dos testes, pode ser observada nas Figuras 5 e 6.
Figura 5 – Etapa Refactor do ciclo TDD
Figura 6 – Etapa Refactor do ciclo TDD (continuação)
Conforme destaca Madeyski (2010), esse processo incremental não apenas assegura o atendimento imediato dos requisitos, mas também gera uma documentação viva por meio dos próprios testes automatizados, que descrevem formalmente o comportamento esperado do sistema. Assim, o ciclo Red-Green-Refactor possibilita que cada nova funcionalidade seja validada, consolidada e refinada em pequenos passos, promovendo um desenvolvimento mais confiável, iterativo e sustentável.
3.3 Vantagens do TDD
A adoção do TDD está associada a diversos benefícios que justificam seu destaque no cenário da engenharia de software. Um dos mais relevantes é a redução de defeitos, já que os testes escritos antes da implementação permitem identificar falhas ainda nas etapas iniciais do desenvolvimento. Essa característica contribui para a diminuição de retrabalho e para a entrega de sistemas mais estáveis e confiáveis (GEORGE; WILLIAMS, 2004; NAGAPPAN et al., 2008).
Outro aspecto importante refere-se à melhoria da qualidade interna do código. O ciclo contínuo de refatoração estimula a criação de soluções mais limpas, modulares e organizadas, favorecendo o reuso de componentes e reduzindo duplicações desnecessárias. Essa prática contribui diretamente para a manutenibilidade e escalabilidade do software, características essenciais em projetos de longo prazo (FOWLER, 1999).
O TDD também se destaca por gerar uma documentação executável, uma vez que os próprios testes descrevem o comportamento esperado do sistema. Essa documentação viva facilita a compreensão do código, reduz ambiguidades nos requisitos e auxilia no processo de integração de novos desenvolvedores à equipe (MARTIN, 2008). Diferentemente da documentação tradicional, sujeita a desatualizações, os testes permanecem alinhados ao estado real do sistema, servindo como guia confiável para manutenção e evolução.
Outro benefício amplamente reportado é o aumento da confiança no processo de desenvolvimento. O feedback imediato proporcionado pelos testes automatizados permite que os desenvolvedores realizem alterações ou incrementos com maior segurança, reduzindo o risco de introdução de regressões. Essa confiança estimula práticas de experimentação e inovação, ao mesmo tempo em que promove um ambiente colaborativo mais produtivo (JANZEN; SAIEDIAN, 2005).
Além dos aspectos técnicos, o TDD contribui para a consolidação de uma cultura organizacional voltada à qualidade, em que a responsabilidade pela confiabilidade do sistema é compartilhada por toda a equipe. Esse alinhamento favorece a adoção de metodologias ágeis em sua forma plena e fortalece a integração entre membros, resultando em entregas mais consistentes e alinhadas às expectativas do negócio (UYAGUARI et al., 2022).
3.4 Desafios e Limitações
Apesar das inúmeras vantagens, a adoção do TDD enfrenta desafios que limitam sua disseminação em determinados contextos. Um dos principais está relacionado à curva de aprendizado. Escrever testes antes da implementação exige disciplina e mudança de mentalidade por parte dos desenvolvedores, o que pode gerar resistência, sobretudo entre aqueles habituados a métodos tradicionais de programação. Essa adaptação inicial costuma demandar treinamento, prática contínua e acompanhamento, fatores que nem sempre estão disponíveis em todas as organizações (KOSKELA, 2008).
Outro obstáculo recorrente refere-se ao esforço adicional nas fases iniciais do desenvolvimento. Como a técnica exige a elaboração de testes antes do código, há um aumento perceptível do tempo necessário para iniciar a implementação de novas funcionalidades. Em ambientes caracterizados por prazos rígidos ou alta pressão por entregas rápidas, esse custo inicial pode ser visto como impeditivo, mesmo que, no longo prazo, o TDD reduza falhas e retrabalho (FUCCI et al., 2018).
A cobertura de testes também representa uma limitação prática. Embora o TDD incentive a validação contínua, nem todos os cenários de uso podem ser facilmente traduzidos em testes automatizados. Integrações complexas, interações com sistemas legados ou requisitos não funcionais, como desempenho e segurança, muitas vezes extrapolam o escopo direto da técnica, exigindo o uso combinado de outras estratégias de verificação (ASTELS, 2003). Questões organizacionais e culturais igualmente impactam a eficácia da prática. Sem suporte institucional, políticas de incentivo ou um ambiente propício à experimentação, o TDD tende a ser aplicado de forma parcial ou abandonado ao longo do tempo. Estudos indicam que a adoção bem-sucedida está diretamente relacionada à maturidade ágil das equipes e ao comprometimento da gestão em oferecer treinamento e recursos adequados (SANTOS; GOLDMAN, 2018).
Por fim, os resultados do TDD em termos de produtividade permanecem pouco uniformes. Enquanto pesquisas confirmam ganhos claros na qualidade do software, os efeitos sobre eficiência e tempo de entrega variam de acordo com fatores como complexidade do sistema, experiência da equipe e contexto organizacional (UYAGUARI et al., 2022). Essa variabilidade reforça que o TDD não deve ser interpretado como solução universal, mas como prática que requer adaptação ao ambiente em que é aplicada.
4. CONCLUSÃO
O Test-Driven Development consolidou-se como uma prática relevante no desenvolvimento de software por sua capacidade de promover qualidade, modularidade e confiabilidade no código. A literatura revisada evidencia benefícios consistentes, como a redução de defeitos, a melhoria do design, a criação de documentação executável e o fortalecimento de uma cultura de qualidade compartilhada entre os membros da equipe. Esses fatores tornam o TDD uma ferramenta estratégica para organizações que buscam produtos digitais mais robustos e sustentáveis.
Entretanto, a técnica também apresenta desafios que não podem ser ignorados. Entre eles, destacam-se a curva de aprendizado acentuada, o esforço adicional nas fases iniciais, a limitação na cobertura de determinados tipos de teste e a dependência de fatores organizacionais, como treinamento adequado e suporte institucional. Além disso, os impactos do TDD sobre a produtividade permanecem pouco uniformes, variando de acordo com a maturidade da equipe, a complexidade do sistema e o contexto de aplicação.
Dessa forma, conclui-se que o TDD não deve ser encarado como solução universal, mas como uma prática que, quando aplicada de forma disciplinada e integrada a outras metodologias ágeis, pode gerar ganhos significativos em qualidade e confiabilidade do software. Recomenda-se que sua adoção seja gradual e acompanhada de políticas de incentivo e capacitação, de modo a minimizar barreiras iniciais e assegurar resultados sustentáveis.
Para pesquisas futuras, destaca-se a necessidade de estudos mais robustos sobre sua aplicação em ambientes industriais de grande escala, em equipes distribuídas e em cenários emergentes, como a prática assistida por Inteligência Artificial. A investigação desses contextos pode contribuir para uma compreensão mais abrangente do real potencial do TDD, bem como de suas limitações, fornecendo subsídios para sua evolução e consolidação como prática de engenharia de software.
5. REFERÊNCIAS
AMBLER, W. Agile Modeling: Effective Practices for eXtreme Programming and the Unified Process. New York: John Wiley & Sons, 2004.
ASTELS, D. Test-Driven Development: A Practical Guide. Upper Saddle River: Prentice Hall, 2003.
BECK, K. Test-Driven Development: By Example. Boston: Addison-Wesley, 2003.
FOWLER, M. Refactoring: Improving the Design of Existing Code. Boston: Addison-Wesley, 1999.
FUCCI, D; ROMANO, S; BALDASSARRE, T; CAIVANO, D; SCANNIELLO, G; TURHAN, B; JURISTO, N. A longitudinal cohort study on the retainment of test-driven development. In: Proceedings of the 12th International Symposium on Empirical Software Engineering and Measurement (ESEM). 2018.
GEORGE, B; WILLIAMS, L. A structured experiment of test-driven development. Information and Software Technology, v. 46, n. 5, p. 337-342, 2004.
JANZEN, S; SAIEDIAN, H. Test-driven development: Concepts, taxonomy, and future direction. Computer, v. 38, n. 9, p. 43-50, 2005.
KITCHENHAM, B; BRERETON, P; BUDGEN, D; TURNER, M; BAILEY, J; LINKMAN, S. Systematic literature reviews in software engineering — a systematic literature review. Information and Software Technology, v. 51, n. 1, p. 7-15, 2009.
KOSKELA, L. Test Driven: TDD and Acceptance TDD for Java Developers. Greenwich: Manning, 2008.
MADEYSKI, L. The impact of test-driven development on software development productivity — an empirical study. Software Process: Improvement and Practice, v. 15, n. 3, p. 297-320, 2010.
MARABESI, M; GARCÍA-HOLGADO, A; GARCÍA-PEÑALVO, J. Exploring the connection between the TDD practice and developers’ productivity: A large-scale GitHub dataset analysis. Computers, v. 13, n. 3, art. 79, 2024.
MARTIN, R. Clean Code: A Handbook of Agile Software Craftsmanship. Upper Saddle River: Prentice Hall, 2008.
MUNIR, H; MOAYYED, M; PETERSEN, K. Considering rigor and relevance when evaluating test-driven development: A systematic review. Information and Software Technology, v. 56, n. 4, p. 375-394, 2014.
NAGAPPAN, N; MAXIMILIEN, M; BHAT, T; WILLIAMS, L. Realizing quality improvement through test-driven development: Results and experiences of four industrial teams. Empirical Software Engineering, v. 13, n. 3, p. 289-302, 2008.
NORTH, D. Introducing BDD. Better Software Magazine, v. 8, n. 3, p. 30-35, 2006.
PAGE, J; MOHER, D; BOSSUYT, M; BOUTRON, I; HOFFMANN, C; MULROW, D; SHAMSEER, L; TETZLAFF, M; AKL, A.; BRENNAN, E; CHOU, R; GLANVILLE, J; GRIMSHAW, M; HRÓBJARTSSON, A; LALU, M; LODER, W.; MAYO-WILSON, E; McGUINNESS, A; STEWART, A; THOMAS, J; TRICCO, C; WELCH, A; WHITING, P;
McKENZIE, P. 2020 explanation and elaboration: updated guidance and exemplars for reporting systematic reviews. BMJ, v. 372, n. 71, 2021.
PENG, S; KALLIAMVAKOU, E; CIHON, P; DEMIRER, M. The Impact of AI on Developer Productivity: Evidence from GitHub Copilot. arXiv: 2302.06590, 2023.
RAHMAN, S; SAHA, K; CHAKRABORTY, U; SUJANA, T; SHAFI, A. Evaluating the impact of Test-Driven Development on Software Quality Enhancement. International Journal of Mathematical Sciences and Computing, v. 10, n. 3, p. 51-76, 2024.
SANTOS, D; GOLDMAN, A. An exploratory study on the adoption of test-driven development in academia and industry. In: Proceedings of the 40th International Conference on Software Engineering: Companion Proceedings. ACM, 2018.
UYAGUARI, F; ACUÑA, T; CASTRO, W; DIESTE, Ó; JURISTO, N. Reliability of systematic literature reviews on Test-Driven Development. Information and Software Technology, v. 150, p. 106989, 2022.
¹Graduando do Curso de Sistemas de Informação da Universidade de Araraquara- UNIARA. Araraquara-SP.
E-mail: gmgaspar@uniara.edu.br
²Orientador Docente do Curso de Sistemas de Informação da Universidade de Araraquara- UNIARA. Araraquara-SP. E-mail: mirellafarina@yahoo.com.br