Development_ (Desenvolvimento Guiado pelos Testes). Significa que os testes vao guiar o desenvolvimento. _"Mas guiar em qual sentido?"_, voce pode perguntar. Guiar no sentido de indicar se a sua arquitetura esta indo na direcao certa.Um dos objetivos de TDD e te mostrar se o que voce esta fazendo esta simples de ser testado. Se for complicado preparar o caminho para fazer o teste, isso pode ser um indicio de problema.Lembra quando eu falei que para rodar os testes automatizados o sistema precisaria estar em um ambiente controlado? E esse ambiente controlado que TDD te ajuda a criar. Um ambiente onde o envio de e-mail nao envia uma mensagem de fato, mas simula o envio. Um ambiente onde o arquivo de transferencia bancaria nao e transferido de fato, mas e simulado. Se estiver dificil preparar seu programa para fazer essas simulacoes, voce precisa mexer na arquitetura do sistema para deixar essa simulacao (teste) mais simples. Outra vantagem do ambiente simulado e que voce pode e deve aplicar [tecnicas para acelerar os testes](/2016/09/como-escrever-testes-rapidos.html).Em outras palavras, um dos objetivos de TDD e tornar seu sistema simples para ser testado. Se ele for complicado para testar, sera complicado para adaptar futuramente.O outro objetivo e saber se ele funciona como deveria, em um ambiente de testes.Se os testes guiam o desenvolvimento, um outro beneficio de praticar TDD e escrever somente o que for necessario para atender o que o cliente precisa. Nada mais, nada menos. Se o teste passou, paramos por ai.Quando o cliente pedir uma modificacao qualquer, seguimos os seguintes passos:1. Modificamos primeiro o programa de teste para adequa-lo ao novo requisito.1. Rodamos o teste para certificar que ele vai mostrar um erro. Afinal, ainda nao ajustamos o sistema real.1. Alteramos o sistema para atender ao teste.1. Rodamos o teste para ver o resultado OK.Depois de ver o teste funcionando, podemos melhorar o codigo do sistema, para que ele fique mais rapido ou mais organizado, por exemplo. A cada modificacao, rodamos os testes. Se mostrarem algum erro, corrigimos o sistema. Se mostrarem resultado OK, significa que melhoramos o sistema sem estraga-lo.A esse ciclo chamamos de _Red, Green, Refactor_ (Vermelho, Verde, Refatorar). [Pequenos passos](/2016/04/pq-desenvolver-um-sistema-usando-baby-steps.html) para atingir grandes objetivos.Quantas vezes mexemos em um ponto do sistema, testamos manualmente, para so depois de implantar, percebermos que afetamos uma outra parte, que aparentemente nao tinha nada a ver com a alteracao? Quem nunca passou por isso?Eis aqui outra vantagem do TDD: voce tem a seguranca de mexer no sistema sem estraga-lo.Eu costumo dizer que os testes funcionam como uma rede de protecao contra defeitos. Essa rede deve ser mais forte ou menos forte dependendo do peso que ela deve aguentar. Se o seu sistema for simples, ela nao precisa ser tao forte. Se o sistema for muito complexo, ela deve ser bastante reforcada.Mas nem tudo sao flores no desenvolvimento de software, nem praticando TDD. Tambem temos espinhos. Como diz um amigo meu:> Testar um sistema nao significa que ele esteja certo. Significa apenas que ele passou no teste.Essa e uma verdade. Por isso e provavel que voce se depare com