Daniel Tamiosso

Quem tem utilizado desenvolvimento orientado por testes (TDD) sabe o quanto ele está diretamente ligado a design de código. Um design testável normalmente é um design desacoplado e reutilizável. TDD é muito mais sobre design do que sobre testes.

TDD é uma prática que envolve o desenvolvimento como um todo. Principalmente o design. Há quem diga que a sua última letra, a letra D, deveria significar design e não desenvolvimento. Ou seja, design orientado por testes.

Eu, particularmente, gosto muito dessa idéia. É como ter um design executável. TDD questiona o desenvolvedor freqüentemente sobre questões como princípio da responsabilidade única (SRP) e não se repita (DRY). Trata as violações das práticas de orientação a objetos. E ataca os pontos mais humanos, simplificando o projeto, onde se implementa somente o necessário (YAGNI).

Esses questionamentos são feitos a medida que sentimos a menor dificuldade em testar alguma coisa. Porque eu preciso depender de outro objeto pra testar apenas esse? Será que esse método deveria funcionar quando chamado por ele mesmo? Esse não era pra ser apenas um método de comando? Então porque alterou meu objeto?

TDD encoraja a testar e verificar cada componente do software independentemente. Isso faz o design emergir de forma extremamente simples e poderoso. Simples por tornar qualquer futura mudança ou manutenção fácil e rápida. Poderoso pela facilidade de extensão com um alto grau de segurança. Como estamos trabalhando com o teste executando a tarefa de um consumidor final e direto, conseguimos alcançar coesão e baixo acoplamento naturalmente. Passo a passo.

Sabemos que a qualidade do design de um software é também relacionada ao conhecimento da equipe de desenvolvimento em relação ao domínio em questão. E TDD também é extremamente influente nesse quesito. Tendo como testes executáveis o primeiro ciclo do desenvolvimento, é no mínimo necessário o desenvolvedor saber o que estará testando e onde ele quer chegar. É ele quem vai desenvolver os critérios de aceitação.

É impossível praticar TDD sem refatoração constante. E esse é o ponto-chave. Usufruindo dos ciclos de refatoração estamos a todo o momento focado no design. Coisa que não acontece em um fluxo tradicional de desenvolvimento.

Engana-se aquele que afirma que TDD não é produtivo. Muito pelo contrário. Por mais que em um primeiro momento o pareça improdutivo, definitivamente ele não é. No momento que focamos no design, e somente no que é essencial já estamos garantindo baixo desperdício. Sem contar que com todo o nosso código coberto por testes, evitamos aquelas longas sessões de depuração. E claro, sem falar no design. Legível, flexível, simples, eficiente, cuidadoso… De fácil manutenção. Quer algo mais produtivo? Sem contar que estamos movendo naturalmente para a idéia de zero defeito. E quanto mais defeitos mais retrabalho.

Uma ótima série de artigos escritos por Neal Ford, sobre arquitetura evolucionária e design emergente, mostra na prática o impacto que TDD causa no design de um software.

Aposte suas fichas no desenvolvimento guiado por testes e veja o design do seu código emergir com qualidade.

Versão em espanhol, por Diego Gomez: El impacto de TDD en tu diseño

Popularity: 24% [?]

Acabei de ler um post de um grande amigo e colega, Lucas Toniazzo, sobre a adoção do ensino de métodos ágeis dentro do ensino superior. Juntando essa leitura, com a participação no Agile Weekend 2009 e o meu dia-a-dia como estudante de desenvolvimento de software em uma universidade, retrato o cotidiano.

Ao surgir a oportunidade de participar de um projeto internacional, decidi trancar o curso de Sistemas de Informação, por mais de um ano. No início desse ano acabei voltando ao convívio acadêmico e fiquei realmente espantado em como algumas coisas (para não dizer a maioria) demoram em chegar lá. Tive a possibilidade de, em uma determinada cadeira, apresentar como é o desenvolvimento de software na empresa na qual eu faço parte. O desinteressante foi saber que pelo menos 90% dos alunos ali presentes jamais tinham sequer ouvido falar em métodos ágeis. Nem uma discussão foi possível. Ninguém gritando “Eu odeio métodos ágeis”, ou algo do tipo. O professor, também, me pareceu muito distante do assunto. Foi realmente frustrante. Como bom gringo, eu precisava de pelo menos uma argumentação mais forte, ou qualquer coisa do tipo. Mas nada aconteceu nesse sentido.

Imagine então entrar em termos mais específicos, tais como desenvolvimento orientado a testes, implantação contínua, desing incremental, desenvolvido orientado por domínio. Nem XP, muito menos Scrum, e Lean então? Agora se o assunto for o nível de maturidade em um determinado processo de avaliação (CMM, MPB.BR…), o rumo da conversa já muda. Não que eu acho que seja ruim conhecer e discutir sobre esse assunto, muito pelo contrário, mas será que não se pode buscar outras formas de pensar em desenvolvimento de software? Esquecer essas verdades absolutas, pensar de um ponto de vista mais humano. Em pensar que uma coisa é arte, outra coisa é manufatura e outra coisa é software? Que existem muitos lados para uma mesma moeda?

Não, não estou querendo que tratem o agile como a salvação do planeta, que o coloquem em cena como um Deus. Só gostaríamos que os responsáveis diretos na formação de novos profissionais de TI instiguem, nós alunos a buscar, a estudar, a praticar, a compartilhar e a, quem sabe, ensinar. Mas sair da zona de conforto dói. Uma situação que eu achei interessante no evento, foi a participação de um professor da instituição ter se interessado e participado do mesmo. Pena foi o ver desistindo do evento antes da metade da segunda palestra. Será que dói tanto assim?

Então como não podemos mudar isso de uma vez por todas, podemos dentro das nossas universidades começarmos, com pequenos passos, a plantar essa semente. O Lucas está entusiasmado e me mostrou muitas possibilidades de mudar essa história. Mas a idéia mais palpável que ele me mostrou foi à criação de grupos de estudos dentro das mesmas. Assim como faz o GUMA, ao qual eu não tenho como descrever o tamanho do brilhantismo deles. Vamos compartilhar, vamos intrigar – no bom sentido – e vamos crescer juntos. Ou pelo mostrar que pode ser diferente.

Na busca por agilizar o ensino de métodos ágeis no meio acadêmico, segue uma mensagem do Lucas, a qual eu apoio totalmente:

Fica aqui então a sugestão para aqueles que tem abertura dentro das universidades ou até mesmo alunos que passam por aqui para dar uma olhada o incentivo a todos para formação de grupos de estudos.

Popularity: 27% [?]