Test-Driven Development - Adoção sem Aprovação

Algumas práticas ágeis causam um grande impacto no ambiente. Frequentemente envolvem mais de uma pessoa e, não raro, vários setores da empresa. Mas para praticar o Test-Driven Development (TDD), o desenvolvedor precisa apenas  convencer a si mesmo.

Introdução ao TDD na Prática

A ideia de mostrar uma introdução ao TDD na prática nasceu da dificuldade que encontrei de visualizar como funciona, quando eu estava começando a brincar com a técnica. Na verdade, é complicado ver como escrever um código que testa um método de uma classe sem antes escrever a classe. Mas com o tempo nos acostumamos e chega a virar um vício.

Um Momento para a Qualidade

Por que não reservar um momento para refletir nas soluções? Se usarmos alguns minutos do dia refletindo no que estamos fazendo, não impactaremos o cronograma de forma decisiva. E o ganho obtido pode, simplesmente, anular o tempo gasto.

Como testar com JUnit

Neste post, vou mostrar como é fácil usar a versão 4.8.1 do JUnit, que pode ser encontrada no site oficial. Além disso, pretendo mostrar como não ferir a Lei de Demeter em uma situação corriqueira, objetos com listas.

Quando estão trabalhando com listas, algumas pessoas tendem em apenas expor o atributo através de um getter. É mais simples.

[Noticia] Como o TDD e a programação em par aumentam a produtividade

Bem, acredito que vai ser difícil achar uma notícia que esteja mais no contexto desse blog que essa. O conteúdo dessa matéria da InfoQ diz tudo que eu sempre debati com as pessoas que questionam a necessidade de um software de qualidade.

Como diz o grande Shoes, Programadores Profissionais Escrevem Testes, Ponto Final.

Isso deveria ser óbvio, mas infelizmente, não é. Nas grandes empresas, onde existe divisão de papéis, quase sempre bem definida, conhecemos desenvolvedores dizendo que não tem a responsabilidade de testar.

O fato da empresa possuir uma equipe de testes, não exime o programador de testar o que fez. Verificar se o que foi implementado cumpre os requisitos é obrigação de todo desenvolvedor. Leia o texto do Philipp e tente não se convencer disso.

Uma suite de testes bem feita garante a qualidade do trabalho do profissional e, parodiando o Shoes, ponto final.

A questão do pair-programming já é um pouco mais complicada, já que envolve a alocação de dois colaboradores da empresa para a mesma tarefa. Essa técnica pode gerar discussões como: É impossível escrever todo o código em pares. Será muito lento. E se duas pessoas não se entenderem? A não ser que:

• Os padrões de codificação reduzam brigas mesquinhas;
• todo mundo esteja descansado e tranquilo, reduzindo mais ainda a chance de discussões não proveitosas;
• os pares escrevam testes juntos, o que dá a eles a chance de se sintonizarem antes de começarem a implementação;
• os pares tenham a metáfora para apoiar suas decisões sobre nomeação e projeto básico;
• os pares estejam trabalhando com um projeto simples, para que os dois entendam o que está acontecendo.

Trecho retirado do livro Programação Extrema Explicada - Kent Beck.

O próximo artigo da série princípios de projeto está quase pronto. Será abordada a questão da eficiência.

Sites Relacionados:
Fonte da Notícia: InfoQ