O Que Estamos Perdendo ao Ignorar o TDD?

"O verdadeiro valor do TDD é o feedback. Ele te avisa onde você está falhando, onde o design está tortuoso, onde o código não faz sentido." — Michael Feathers

A pressão para concluir rapidamente uma nova funcionalidade muitas vezes nos leva a pensar que o mais importante é entregar algo que “funcione” no curto prazo. Mas será que realmente estamos satisfeitos com um código que só se sai bem no caminho feliz dos testes? Pense em um código que no inicio é fácil de manter, mas ao passar dos meses bugs surgem, o acoplamento cresce e fica difícil de manter… será que estamos ignorando algo? Você já deve conhecer o TDD — Test-Driven Development — mas já parou para pensar no que ele realmente nos oferece para aprimorar nosso código e nossa forma de pensar e escrever testes?

O TDD vai além de simplesmente “fazer o código funcionar.” Imagine um processo onde o código não apenas cumpre o que foi solicitado, mas também antecipa problemas, revela oportunidades de melhoria e permite refinamentos constantes. Vamos comentar sobre isso em breve e também sobre como cada ciclo de “Red-Green-Refactor” nos dá uma chance de aprimorar o design, melhorar a estrutura e garantir que cada parte do sistema esteja harmonizada com o todo.

Neste artigo, vamos explorar o que o TDD realmente nos oferece. Vamos falar sobre como ele transforma a forma de encarar o código e nos obriga a observar com uma perspectiva crítica e detalhista. Vamos entender juntos o valor do feedback constante e como ele nos ajuda a evitar surpresas desagradáveis, construindo um código que não só responde aos requisitos de hoje, mas que está preparado para os desafios de amanhã.

Se gostar do conteúdo, por favor, compartilhe e deixe seu like no post! Isso me ajuda a continuar a trazer conteúdos em forma de texto!😄

O Dia a Dia de um Engenheiro de Software: Como Codificamos, Testamos e Mantemos o Código

Vamos falar sobre o nosso dia a dia como engenheiros de software. Qual é o nosso processo quando recebemos uma nova tarefa ou começamos a trabalhar em uma funcionalidade? Em geral, começamos entendendo os requisitos, conversando com a equipe, analisando o que já existe e tentando encaixar a nova lógica no sistema. Às vezes, estamos em equipes que discutem detalhadamente os requisitos, mas em outros momentos, lidamos sozinhos com essas decisões, mergulhando diretamente no código.

Na prática, estamos sempre equilibrando expectativas. Precisamos fazer o código funcionar e entregar algo que atenda ao que foi solicitado. Muitas vezes, trabalhamos sob prazos, e isso pode limitar a profundidade do nosso planejamento e testes. Pensamos em como resolver o problema da forma mais rápida e funcional possível, e nem sempre temos tempo para explorar todas as possibilidades de erro ou antecipar desafios futuros. Os testes, então, acabam ficando para depois, ou são executados de forma mais focada nos caminhos felizes e nas funcionalidades principais.

E quando se trata de manutenção? Com o tempo, vamos acumulando funcionalidades e correções que nem sempre foram testadas de maneira ideal. O código vai crescendo, e aos poucos ele se torna uma colcha de retalhos de funcionalidades, com dependências que às vezes nem sabíamos que existiam. O que começou como uma estrutura clara pode se tornar algo mais complexo e difícil de modificar, especialmente se não consideramos a coesão e o acoplamento logo no início.

Agora, pense em todos esses aspectos: requisitos, prazos, implementação e manutenção. O que realmente precisamos melhorar nesse processo todo? Como podemos fazer para que nosso código evolua de maneira mais organizada, com menos retrabalho e menos surpresas desagradáveis ao longo do caminho?

É aqui que chegamos a uma pergunta central: O que o Desenvolvimento Orientado a Testes nos oferece?

O que o Desenvolvimento Orientado a Testes nos oferece?

Você já escreveu uma funcionalidade e só descobriu problemas nela durante um code review ou, pior, depois que o sistema já estava em produção? Eu já 😂. É uma sensação nada agradável quando alguém mais experiente aponta uma falha que você não enxergou, questiona a complexidade desnecessária do seu algoritmo ou menciona um acoplamento. Esse feedback é importante, sem dúvida, mas muitas vezes chega tarde demais, quando a lógica já está montada e corrigir significa refazer, adaptando o código a uma estrutura que não foi pensada para suportar mudanças.

Então, o que o TDD tem a nos oferecer? Feedback. Imagine a diferença que seria receber esses insights antes mesmo de codificar a funcionalidade, em um ambiente seguro, onde os problemas emergem nos testes — e não nas mãos do usuário ou durante um code review. Com o TDD, cada ciclo de testes nos alerta sobre possíveis problemas no design ou na lógica enquanto ainda estamos na fase de desenvolvimento, dando-nos a chance de ajustar antes que se torne algo maior.

É exatamente isso que o TDD oferece: um processo onde o feedback não só chega a tempo, mas orienta cada passo. Isso permite que o código seja desenvolvido de forma mais segura e sustentável, com problemas resolvidos no momento certo, antes que possam comprometer a estrutura ou a integridade do sistema.

Imagine, por exemplo, que você está criando uma funcionalidade que calcula o desconto para um tipo específico de cliente. Sem o TDD, você talvez avance diretamente para o código, crie algumas condições e trate os valores de maneira intuitiva. O problema é que, sem ser guiado por testes, tendemos a focar apenas no caminho feliz — aquele cenário ideal onde tudo funciona como planejado. Assim, é fácil ignorar casos extremos, como descontos para clientes com condições especiais ou situações onde a lógica do cálculo falha.

Em um code review, alguém pode apontar essa falta de cobertura, mas a complexidade da correção aumenta, pois agora você precisa ajustar toda a lógica, e, se o algoritmo se mostrou frágil, isso afeta diretamente a estrutura do design.

O TDD, por outro lado, traz à tona esses pontos críticos desde o início. Quando você escreve o primeiro teste, ele já está questionando, por exemplo se você está programando funcionalidades de uma jornada de um e-commerce: “E se o cliente for especial? E se o desconto for muito alto?” Esses questionamentos não esperam uma validação externa; eles vêm de você mesmo, com o apoio do TDD. É o famoso “afastamento do código” — você deixa de ser apenas o autor e passa a ser também o crítico, o usuário, o testador. Esse distanciamento permite que você observe o código sob várias perspectivas, identificando falhas antes mesmo que outro desenvolvedor tenha a chance de apontá-las.

Esse tipo de autocrítica, impulsionado pelo TDD, é muito poderoso. E é aqui que o pensamento crítico realmente se destaca: você passa a antecipar cenários, imaginando situações onde o sistema poderia falhar e forçando o código a se fortalecer contra esses casos. Não é mais apenas uma questão de passar nos testes, mas de transformar o código em algo mais sólido e coeso.

O TDD como um Mapa para o Desenvolvimento

Talvez você não goste de pensar no TDD como um mapa. Talvez veja o TDD como uma técnica de teste puro e simples, sem grandes comparações. Mas pense comigo: assim como um mapa, o TDD nos orienta em cada etapa da jornada. Ele nos oferece feedback rápido sobre onde estamos e se estamos no caminho certo, mostrando logo no início onde ajustes são necessários. Em vez de esperar até o final para perceber um problema — o que poderia comprometer o design ou até mesmo gerar retrabalho — o TDD nos alerta rapidamente, mantendo-nos no rumo certo.

Outra vantagem de pensar no TDD como um mapa é o direcionamento sem rigidez. Um mapa nos mostra o destino final e sugere vários caminhos, mas não nos impõe uma rota única. Podemos fazer desvios, ajustar o percurso, contornar obstáculos. Da mesma forma, o TDD nos dá clareza sobre o objetivo de um código funcional e testável, mas oferece flexibilidade para que adaptemos o design conforme avançamos. Ele revela problemas e nos dá opções para resolvê-los, sem ditar uma solução única. Com o TDD, temos a liberdade de escolher a melhor rota, sempre mantendo o código simples e modular.

E o que acontece quando tentamos navegar sem um mapa? Fica fácil se perder, só percebendo o erro tarde demais, depois de já termos tomado várias decisões equivocadas. No desenvolvimento, ao ignorarmos o TDD, corremos o risco de criar um design acoplado e complexo, descobrindo esses problemas apenas em fases avançadas, quando as correções são mais difíceis e custosas. Com o TDD, recebemos feedback constante sobre a qualidade do design e temos uma visão clara do objetivo final. Isso nos permite fazer ajustes no momento certo, mantendo o código funcional, alinhado e sustentável.

"TDD é como um mapa de navegação no desenvolvimento. Ele não só ajuda você a chegar ao destino, mas revela os melhores caminhos."
— John Ferguson Smart, "BDD in Action"

Assim, o TDD vai além de ser uma técnica de teste — ele é uma ferramenta de navegação, que orienta nossas decisões e nos ajuda a manter o desenvolvimento no curso certo, evitando desvios e garantindo que o código esteja preparado para responder a qualquer desafio.

Exercitando o Pensamento Crítico com TDD

Vamos explorar o que significa codificar sem o apoio e feedback constante do TDD. Pense em um cenário comum: você recebe uma especificação de requisito de software. Sem TDD codificamos diretamente a funcionalidade descrita, validamos o fluxo básico e, uma vez que o código parece “funcionar”, seguimos em frente. Mas será que ele realmente cobre todas as condições possíveis? E quanto aos casos de uso extremos, os limites de entrada e os cenários improváveis, mas plausíveis?

Quando não temos o TDD como guia, é fácil ignorar essas nuances ou deixar algumas para trás. A tendência é pensar que, se o caminho feliz está funcionando, o sistema está pronto para ser entregue. Muitas vezes, o feedback que recebemos chega tarde demais, expondo a necessidade de refatorar o código e exigindo ajustes significativos que poderiam ter sido evitados.

O Significado e a Importância do Feedback

Mas o que é feedback e por que ele é tão essencial no desenvolvimento de software? A palavra “feedback” vem do inglês e tem raízes na ideia de “feed” (alimentar) e “back” (de volta), transmitindo o conceito de uma informação que retorna ao seu ponto de origem. O Dicionário Oxford define feedback como “informação sobre reações a um produto, ação ou desempenho, usada como base para melhorias.” Já o Cambridge Dictionary descreve feedback como “informação ou críticas sobre algo, que serve para ajudar a melhorar ou corrigir o que foi feito.” Em resumo, feedback é um retorno que informa como algo está funcionando e sugere ajustes ou confirmações.

Na engenharia de software, o feedback é a forma como verificamos se estamos no caminho certo. Ele valida ou questiona as decisões que tomamos, apontando áreas de melhoria e ajudando a corrigir erros antes que se tornem problemas maiores. Essa troca constante de informações nos permite evoluir o código de maneira progressiva e orientada.

Porém, em muitos fluxos de trabalho, o feedback é reativo. Sem o TDD, por exemplo, dependemos de revisões de código feitas por colegas ou de testes de integração para identificar problemas, feedback que, muitas vezes, chega tarde, quando a estrutura do código já está definida e integrada ao sistema. Esse tipo de feedback reativo pode ser custoso e desgastante, gerando retrabalho e pressão para corrigir falhas às pressas.

Com o TDD, o feedback se torna proativo e constante. Cada teste é uma forma automática de feedback que revela problemas ou validações antes mesmo de o código ser consolidado, orientando nossas decisões a cada etapa. Muitas vezes, esse feedback é tão natural e imediato que nem o percebemos, mas ele está lá, ajustando e confirmando o design continuamente e garantindo que o sistema permaneça no caminho certo.

Como o TDD Transforma o Feedback

Já que o TDD promove um respostas rápidas em ciclos curtos — ele não espera que você chegue ao final do desenvolvimento para revelar o que precisa de ajustes. Em vez disso, cada teste que você escreve traz uma camada de percepção sobre o código, dando feedback imediato sobre o que está funcionando, o que precisa ser melhorado e o que talvez esteja caminhando para um design inadequado. Isso antecipa problemas, ajudando você a tomar decisões mais fundamentadas no momento certo, durante cada ciclo de “Red-Green-Refactor.”

Imagine que você está escrevendo um teste para uma funcionalidade de cadastro. À medida que desenvolve o teste, você percebe que precisa de várias classes de suporte — uma para validar o formato dos dados, outra para persistir as informações e, quem sabe, uma terceira para gerar uma resposta adequada ao cliente. Esse momento é um feedback proativo do TDD, indicando que talvez essa funcionalidade esteja tentando fazer mais do que deveria em uma única classe. É como se cada teste fosse um "checkpoint" que traz perguntas inevitáveis: “Essa funcionalidade está dependendo de muitas coisas para funcionar?”, “Será que isso deveria estar em uma classe separada?”, ou “Como posso isolar essa lógica para facilitar futuros testes?”

Esse tipo de insight transforma a maneira de programar. Em vez de esperar por um code review para perceber que o cadastro está altamente acoplado a múltiplas dependências, o TDD aponta isso automaticamente, possibilitando que você simplifique e ajuste a arquitetura antes que ela se torne difícil de manter.

Com o TDD, o código e os testes “conversam” com você a cada passo, ajudando a enxergar detalhes que poderiam ser esquecidos em uma análise superficial. Cada novo teste é uma nova chance de examinar o código com atenção crítica, corrigir falhas antes que elas cresçam e construir uma base sólida. Assim, o TDD coloca o controle do feedback nas suas mãos e torna o desenvolvimento um fluxo de autoavaliação contínua, onde cada linha de código é escrita com uma mentalidade de melhoria constante.

Evitando Erros Comuns na Interpretação do Feedback

Ainda assim, nem todo feedback é interpretado corretamente. Alguns desenvolvedores aplicam o feedback de forma superficial, corrigindo o erro apontado apenas para que o teste passe, sem questionar a estrutura ou o design do código. Isso resulta em remendos que, a longo prazo, podem comprometer a coesão e a clareza da solução. O TDD, no entanto, incentiva uma análise mais profunda e o questionamento constante sobre a estrutura do código. Não é apenas sobre "fazer o teste passar" — é sobre entender se o design realmente suporta o comportamento esperado e se a coesão do código está sendo respeitada.

Um ponto essencial aqui é a interpretação correta do feedback. Muitas vezes, o TDD sinaliza problemas de design, mas, se o desenvolvedor não possui uma base sólida em princípios de programação orientada a objetos (OOP) ou nos fundamentos de design, ele pode interpretar esse feedback de forma incorreta. Por exemplo, ele pode acabar adicionando métodos ou dependências desnecessárias apenas para "calar" o teste, sem perceber que isso torna a classe inchada e menos coesa. Ou talvez ele veja a necessidade de uma nova dependência como algo a ser adicionado diretamente, sem considerar o impacto no acoplamento e na testabilidade da classe.

Esses erros de interpretação mostram a importância de fortalecer as bases e fundamentos da programação. O TDD fornece insights valiosos sobre o design, mas é necessário ter um bom entendimento de princípios como baixo acoplamento, alta coesão, abstração e encapsulamento para fazer bom uso desse feedback. Caso contrário, o desenvolvedor corre o risco de criar soluções que, embora façam o teste passar, acabam comprometendo a qualidade do código.

Com o TDD, você começa a ver o feedback não como uma resposta final, mas como uma parte constante do processo de aprendizado e aprimoramento do design. O feedback se torna um "conselheiro" presente a cada ciclo, ajudando a garantir que cada decisão esteja alinhada com um design robusto e sustentável. Esse processo contínuo de feedback impacta diretamente a arquitetura do sistema: ele organiza o código em torno de componentes claros e testáveis, promovendo uma estrutura onde cada parte é coesa e bem alinhada ao todo.

"TDD é sobre receber feedback o mais cedo possível, evitando problemas e retrabalho lá na frente."
— Steve Freeman

Ao interpretar corretamente esses sinais e ajustar o design com base nos princípios de programação, o TDD nos guia para criar sistemas mais limpos e modulares. Esse processo fortalece a base do código, tornando-o mais fácil de manter e menos propenso a problemas futuros.

O TDD Como um Guia, Não Como uma Regra

O ponto chave aqui é que o TDD não impõe regras sobre o design; ele apenas nos permite enxergar o impacto das nossas decisões de forma antecipada. Ele nos dá liberdade, mas com clareza. Podemos seguir com um design complexo e centralizado, se essa for a escolha, mas estamos conscientes das possíveis consequências. O TDD transforma o design em algo tangível, onde cada escolha é questionada e cada nova funcionalidade é testada contra os fundamentos do sistema.

"TDD é como um guia invisível: enquanto você programa, ele te lembra o que realmente importa — a funcionalidade correta e o design limpo."

E é isso que torna o desenvolvimento orientado a testes tão poderoso: ele nos convida a construir uma arquitetura que resiste ao teste do tempo. Ao receber feedback antecipado, conseguimos visualizar a estrutura antes de ela ser finalizada. Se um novo recurso começa a criar uma cadeia de dependências que afeta a clareza do sistema, o TDD nos mostra isso. Se os testes estão complexos demais, é sinal de que talvez o design esteja pedindo uma abordagem mais modular, com separação de responsabilidades.

Avaliando o Design com Base nos Testes

Com o TDD, é possível sentir a dificuldade de um design inadequado logo de início. Se para testar um módulo você precisa configurar uma série de outras dependências, talvez esse seja um indício de que ele está acoplado demais. Esse feedback nos ajuda a tomar decisões de design mais inteligentes. Ao simplificar e modularizar, o código se torna naturalmente mais testável, mais compreensível e mais flexível para mudanças futuras.

Outra questão importante é o encapsulamento. O TDD nos alerta quando estamos vazando detalhes internos para fora de uma classe ou módulo. Digamos que você precise expor métodos internos apenas para fazer um teste funcionar. Isso é um sinal claro de que o design precisa ser revisado. Em vez de “abrir” o código para acomodar os testes, o ideal é ajustar a arquitetura para que o módulo se comporte como uma unidade independente e coerente.

Aproveitando o Feedback para Melhorar o Design

A beleza do TDD está justamente na sua simplicidade em apontar os caminhos sem forçar decisões. Ele nos lembra que o design precisa ser tratado com cuidado e que cada função ou módulo deve ter um propósito claro. Quando os testes começam a “gritar” que o design está sobrecarregado ou que a funcionalidade não está isolada como deveria, o TDD está nos mostrando uma oportunidade de melhorar.

No desenvolvimento orientado a testes não estamos apenas escrevendo testes; estamos construindo uma base sólida para o design e a arquitetura do sistema. Cada ciclo de teste nos ajuda a modularizar, desacoplar e alinhar a estrutura do código, preparando o sistema para crescer de forma ordenada e sustentável.

Vamos ver brevemente na prática como o TDD nos ajuda a identificar falhas no design logo no início, pegando um pequeno exemplo de Autorização onde precisamos gerenciar roles (perfis de usuário) e permissões. Imagine que estamos construindo uma funcionalidade para adicionar uma role específica a um usuário, e queremos ter certeza de que apenas os usuários autorizados podem atribuir roles.

Aqui estão alguns requisitos que o programador lê do Backlog:

Requisitos

1. Apenas usuários com permissão de admin devem poder atribuir roles.

2. Caso o usuário não tenha permissão, uma exceção de autorização deve ser lançada.

Antes mesmo de escrever a primeira linha de código, o TDD nos convida a refletir e fazer perguntas importantes sobre o design. Vamos ver algumas dessas perguntas e como elas podem guiar a criação de um código mais robusto e modular.

Antes de Escrever a Primeira Linha de Teste

Antes de começar a escrever o teste, vale a pena questionar co:

1. Quais são os requisitos de permissão e segurança dessa funcionalidade?

   • Sabemos que, para a atribuição de roles, queremos que apenas usuários com perfil de admin possam realizar essa ação. O TDD nos ajuda a garantir que isso seja sempre validado. Pergunte-se: “Como posso garantir que esse controle seja cumprido em qualquer cenário?” Essa reflexão inicial ajuda a estruturar o teste para cobrir tanto os casos de sucesso quanto os casos de falha de permissão.

2. A lógica de autorização deve estar no mesmo lugar da lógica de atribuição?

   • Antes de codar, pergunte-se: “Essa lógica deve estar centralizada ou seria melhor dividi-la para garantir clareza e coesão?” Essa pergunta nos leva a avaliar a estrutura do código antes de escrever o teste, incentivando um design que facilite a manutenção.

3. Como esse recurso pode evoluir no futuro?

   • Ao pensar em como a aplicação pode evoluir, é importante se perguntar: “Se no futuro alguém precisar adicionar novas funcionalidades, como auditoria ou notificações, o design atual permitirá essa extensão sem grandes dificuldades?” Essa reflexão ajuda a identificar possíveis riscos de sobrecarregar uma única classe com várias responsabilidades. Se a resposta indicar que o design atual pode dificultar a expansão, talvez seja o momento de considerar dividir a responsabilidade entre diferentes serviços, promovendo uma arquitetura mais flexível e sustentável.

Essas perguntas iniciais colocam o desenvolvedor no papel de um “arquiteto do código”, alguém que já prevê possíveis problemas de design antes de implementar.

Agora, partimos para o primeiro teste, seguindo o fluxo do TDD para verificar se apenas um usuário com role de admin pode atribuir roles:

public class AuthorizationServiceTest {

    private AuthorizationService authorizationService;
    private User adminUser;
    private User regularUser;

    @BeforeEach
    void setUp() {
        authorizationService = new AuthorizationService();
        adminUser = new User("admin", Role.ADMIN);
        regularUser = new User("user", Role.USER);
    }

    @Test
    void shouldAllowAdminToAssignRole() {
        boolean result = authorizationService.assignRole(adminUser, regularUser, Role.MANAGER);

        assertTrue(result, "Admin user should be able to assign roles");
        assertTrue(regularUser.getRoles().contains(Role.MANAGER));
    }

    @Test
    void shouldThrowExceptionWhenNonAdminAttemptsToAssignRole() {
        assertThrows(AuthorizationException.class, () -> 
            authorizationService.assignRole(regularUser, new User("targetUser"), Role.MANAGER)
        );
    }
}

Análise do Design Baseado no Feedback do TDD

Implementando inicialmente a lógica no AuthorizationService, o código para o método assignRole ficaria assim:

public class AuthorizationService {

    public boolean assignRole(User assigningUser, User targetUser, Role role) {
        if (!assigningUser.getRoles().contains(Role.ADMIN)) {
            throw new AuthorizationException("User does not have permission to assign roles.");
        }

        targetUser.addRole(role);
        return true;
    }
}

Tudo parece funcionar bem com esses testes iniciais. No entanto, o TDD começa a nos dar feedback sobre o design à medida que pensamos em futuros requisitos e nas perguntas que fizemos inicialmente.

Feedback Revelado pelo TDD

Ao rodar os testes, começamos a perceber um problema sutil: o AuthorizationService está acumulando responsabilidades ao concentrar a lógica de verificação de permissão e de atribuição de roles. Imagine que futuramente precisemos registrar quem fez a atribuição de role, ou enviar notificações a respeito da mudança. O AuthorizationService começaria a “inchar” com diversas tarefas, o que comprometeria sua clareza e modularidade.

Pergunta-chave: Será que estamos atribuindo responsabilidades demais a essa classe? O TDD nos sugere que sim e a solução passa a ser segregar essa lógica.

Refatorando com Base no Feedback do TDD

Para resolver isso, vamos dividir o design em duas classes especializadas: o AuthorizationService, que fica responsável apenas por verificar permissões, e o RoleAssignmentService, que se ocupa da atribuição de roles, usando o AuthorizationService para validar as permissões.

Código Refatorado

Agora, o AuthorizationService fica focado apenas na lógica de permissão:

public class AuthorizationService {
    public boolean hasPermission(User user, Permission permission) {
        return user.getRoles().contains(Role.ADMIN);
    }
}

E o RoleAssignmentService verifica a permissão com o AuthorizationService antes de fazer a atribuição:

public class RoleAssignmentService {

    private final AuthorizationService authorizationService;

    public RoleAssignmentService(AuthorizationService authorizationService) {
        this.authorizationService = authorizationService;
    }

    public boolean assignRole(User assigningUser, User targetUser, Role role) {
        if (!authorizationService.hasPermission(assigningUser, Permission.ASSIGN_ROLE)) {
            throw new AuthorizationException("User does not have permission to assign roles.");
        }

        targetUser.addRole(role);
        return true;
    }
}

Reescrevendo o Teste para Validar o Novo Design

Nosso teste agora pode ser atualizado para refletir a nova divisão de responsabilidades. Abaixo está o teste para o RoleAssignmentService:

public class RoleAssignmentServiceTest {

    private AuthorizationService authorizationService;
    private RoleAssignmentService roleAssignmentService;
    private User adminUser;
    private User regularUser;

    @BeforeEach
    void setUp() {
        authorizationService = new AuthorizationService();
        roleAssignmentService = new RoleAssignmentService(authorizationService);
        adminUser = new User("admin", Role.ADMIN);
        regularUser = new User("user", Role.USER);
    }

    @Test
    void shouldAllowAdminToAssignRole() {
        boolean result = roleAssignmentService.assignRole(adminUser, regularUser, Role.MANAGER);

        assertTrue(result, "Admin user should be able to assign roles");
        assertTrue(regularUser.getRoles().contains(Role.MANAGER));
    }

    @Test
    void shouldThrowExceptionWhenNonAdminAttemptsToAssignRole() {
        assertThrows(AuthorizationException.class, () -> 
            roleAssignmentService.assignRole(regularUser, new User("targetUser"), Role.MANAGER)
        );
    }
}

Vamos parar um momento e refletir sobre como o TDD nos guiou nesse processo. Se você voltar ao início, verá que começamos com uma abordagem mais direta, com a classe AuthorizationServiceTest focada em garantir que apenas um usuário com perfil de admin pudesse atribuir roles a outros usuários. Parecia simples e eficiente: tínhamos um serviço (AuthorizationService) que fazia a verificação de permissão e, ao mesmo tempo, cuidava da atribuição de roles.

No entanto, conforme começamos a aprofundar os testes, o TDD começou a nos dar um feedback importante: essa classe estava começando a fazer coisas demais. Ela não apenas verificava permissões, mas também lidava com a lógica de atribuição de roles, o que a tornava uma espécie de “faz-tudo” dentro do contexto de autorização. Esse é o tipo de insight que o TDD nos proporciona: ao escrever e rodar os testes, fica claro onde o design começa a se tornar pesado e difícil de manter.

Foi aí que decidimos separar as responsabilidades. Em vez de concentrar tudo no AuthorizationService, criamos uma nova classe, o RoleAssignmentService. Esse novo serviço ficou responsável pela atribuição de roles, mas ele agora depende do AuthorizationService para validar as permissões. Essa divisão deixa o AuthorizationService focado exclusivamente na lógica de autorização, enquanto o RoleAssignmentService cuida apenas da lógica de atribuição.

"Cada teste em TDD é uma pergunta: 'O que eu espero que esse código faça?' — e a resposta está na execução."
— Kent Beck

O TDD, nesse caso, atuou como um feedback proativo, mostrando que estávamos no caminho de um design acoplado. A necessidade de modularização e clareza de responsabilidades ficou evidente ao tentarmos cobrir cenários de teste mais complexos. Esse é o tipo de ajuste que, sem o TDD, talvez só perceberíamos muito mais tarde, em code reviews ou até em fases de manutenção, quando o sistema já estaria mais sobrecarregado.

Então, essa transição — de um AuthorizationServiceTest para uma estrutura com o RoleAssignmentService apoiando-se no AuthorizationService — não foi só uma decisão técnica, mas uma evolução do design impulsionada pelo TDD. O TDD não nos “obrigou” a nada, mas ele trouxe à tona os pontos fracos do design inicial, permitindo que fizéssemos ajustes importantes desde o começo.

Em resumo, o TDD nos ajudou a perceber que um design mais modular e com responsabilidades bem divididas não só facilita o teste, mas também torna o código mais preparado para evoluções futuras.

O Feedback

O que aprendemos com esse exemplo? O TDD nos deu feedback sobre o design ao sinalizar que o AuthorizationService estava acumulando responsabilidades. Antes mesmo de termos uma estrutura final, o TDD nos mostrou que estávamos no caminho de um design sobrecarregado, onde permissões e atribuições estavam misturadas em um único serviço.

Com o TDD, percebemos que o design precisava de ajuste, e modularizamos o código ao criar um RoleAssignmentService separado. Esse processo não só torna o código mais limpo e organizado, mas também facilita futuras expansões. Agora, por exemplo, podemos adicionar funcionalidades como auditoria ou notificações no RoleAssignmentService sem comprometer a estrutura do AuthorizationService. Cada classe permanece focada em suas responsabilidades específicas.

Outro benefício dessa modularização é que, no futuro, podemos implementar uma interface ou contrato entre as duas classes para definir como elas se comunicam. Isso nos permite evoluir cada componente independentemente. Por exemplo, o AuthorizationService poderia ser substituído por uma implementação de autenticação externa ou integrada com um sistema de gerenciamento de permissões mais robusto, sem que o RoleAssignmentService precise ser alterado.

Esse tipo de desacoplamento é fundamental para a escalabilidade do sistema. O TDD, ao fornecer feedback rápido e claro, nos mostrou os pontos onde o design estava tendendo ao acoplamento excessivo. Ao modularizar e estabelecer fronteiras bem definidas entre as classes, estamos criando uma base de código mais robusta, flexível e preparada para mudanças futuras.

Em resumo, o TDD atua aqui como uma bússola: ele não dita regras, mas nos oferece clareza sobre o design, permitindo que façamos ajustes antes que o sistema se torne difícil de manter. Ao garantir que o código permaneça modular, desacoplado e escalável, o TDD nos ajuda a construir um sistema que é tanto funcional quanto adaptável às demandas futuras.

Começando a Aplicar o TDD Mesmo Quando Ninguém Mais Aplica

Imagine que você está aprendendo a tocar um instrumento. No começo, é desafiador: os dedos parecem não obedecer, as notas não soam como deveriam e você pensa que talvez tenha escolhido o caminho mais difícil. Mas, com o tempo, praticando e corrigindo pequenos erros, você começa a ver progresso. É algo que só você sente, porque ninguém mais ouve esses primeiros sons, nem percebe o esforço por trás de cada nota certa. Praticar o TDD sozinho, em uma equipe onde ninguém mais aplica essa técnica, é um pouco parecido.

Talvez você seja o único no seu time que vê o valor do TDD. E se, além disso, seu gerente ou colegas questionarem a importância de “perder tempo escrevendo testes antes do código”? Pode parecer um cenário desmotivador, mas aqui está um ponto importante: o TDD é uma prática que oferece benefícios que vão aparecendo naturalmente com o tempo. E quem pratica o TDD regularmente começa a perceber algo diferente no desenvolvimento: os ciclos de feedback rápido, que ajudam a criar funcionalidades coesas, fáceis de testar e de manter. Cada ciclo de “Red-Green-Refactor” se torna uma oportunidade de analisar com calma os requisitos, refinar o design e garantir que o código esteja preparado para evoluir. Você começa a ver uma diferença real no seu código e, ao longo do tempo, essa prática se torna um recurso que você leva para cada projeto, seja ou não acompanhado pela equipe.

"A prática de TDD reduz o medo de mudar o código. Mostre aos gestores que um ambiente de desenvolvimento onde as mudanças são seguras e rápidas é um diferencial competitivo."
— Michael Feathers, "Working Effectively with Legacy Code"

Mas como explicar isso para os outros? Como convencer o time ou o seu gerente de que o TDD traz benefícios? Uma boa abordagem é começar mostrando os resultados. Talvez, ao longo de um projeto, você perceba que as partes do código desenvolvidas com TDD são mais estáveis, menos propensas a erros e mais fáceis de adaptar. Compartilhe esses insights com a equipe. Se alguém notar que seu código é mais fácil de revisar ou que suas funcionalidades apresentam menos problemas em produção, aproveite para falar do TDD como parte desse resultado. Diga que, mesmo que pareça um passo a mais, o TDD permite identificar falhas de design e corrigir problemas cedo, evitando retrabalho e garantindo que o código evolua de forma sustentável.

E, se mesmo assim, ninguém quiser aderir? Continue firme. Às vezes, ser o único defensor de uma prática exige paciência, mas os frutos aparecem no longo prazo. Pense em grandes ideias que demoraram a ser aceitas, como os cientistas e inventores que insistiram em suas descobertas mesmo sem apoio. Muitas vezes, a inovação começa com alguém que percebe o valor de algo antes dos demais e, no momento certo, esse diferencial se torna visível. Da mesma forma, você pode continuar aplicando o TDD e colhendo os benefícios, sabendo que ele é uma base sólida para construir um código mais robusto e flexível.

"TDD não é só sobre encontrar bugs; é sobre não deixá-los entrar no código em primeiro lugar. Essa é uma mensagem poderosa para gestores que se preocupam com qualidade e prazos."
— James Shore, "The Art of Agile Development"

Não se desanime se, por um tempo, você for o único. Os efeitos do TDD se acumulam. Com cada ciclo de feedback, você melhora suas habilidades em identificar problemas de design, manter o código alinhado aos requisitos e refinar as funcionalidades de forma independente e eficaz. E quem sabe? Talvez com o tempo, outros na equipe comecem a notar a diferença e fiquem curiosos para entender o que está por trás dessa qualidade que você alcançou.

O Que Estamos Perdendo ao Ignorar o TDD?

Você já parou para pensar no que realmente deixamos para trás ao ignorar o TDD? Talvez ele pareça uma prática que “só toma tempo”, mas o TDD é, na verdade, uma maneira de preparar o código para durar e evoluir. Ao deixá-lo de lado, estamos abrindo mão de um método que promove coesão, clareza e adaptabilidade — qualidades que transformam o desenvolvimento e tornam o código mais fácil de manter.

Pense em sistemas que você conhece, especialmente aqueles que já estão em produção há algum tempo. Quantas vezes uma funcionalidade simples se transformou em uma tarefa complexa de manutenção porque o código está interligado demais? Esse tipo de acoplamento excessivo, que compromete a escalabilidade e a flexibilidade do sistema, é algo que o TDD ajuda a evitar desde o início. Kent Beck, criador do TDD, enfatiza que ele não é apenas uma técnica de teste, mas uma maneira de construir um design sustentável.

Em um monólito, cada mudança pode desencadear uma cadeia de problemas porque a estrutura não foi desenhada para suportar mudanças. E até mesmo em arquiteturas de microserviços, onde cada serviço deveria ser independente e autossuficiente, a falta de TDD pode resultar em um código acoplado, confuso e difícil de manter, mesmo dentro dos limites de um único serviço. Não adianta termos domínios segregados e contextos bem definidos se o código que forma a base de tudo dentro de cada microserviço é frágil, cheio de dependências invisíveis e desorganizado.

"Sem TDD, o desenvolvimento se torna mais reativo. Você descobre os problemas tarde demais, geralmente quando o impacto já é grande."
— Michael Feathers, "Working Effectively with Legacy Code"

O que realmente estamos perdendo ao ignorar o TDD é a chance de construir um sistema onde o design é constantemente aprimorado e problemas são detectados cedo. O TDD não é apenas sobre corrigir falhas: ele promove um ciclo de feedback contínuo que ajusta o design de forma proativa, prevenindo a formação de “dívidas de design”. É uma escolha de longo prazo, que prepara o código para mudanças sem comprometer a estrutura.

Portanto, o TDD não deve ser visto como um passo extra, mas como uma prática essencial para construir sistemas que não se tornam frágeis com o tempo. Ao contrário, eles ganham flexibilidade e resiliência, prontos para evoluir e atender às demandas do futuro.