Breno Barros

Agilidade de Ponta-a-Ponta com Arquiteturas Evolucionárias

Agilidade de Ponta-a-Ponta com Arquiteturas Evolucionárias View more presentations from Breno Barros

Você continua usando TDD para testes? Você está com sérios problemas.

Minha motivação para escrever post, partiu da percepção que até hoje muitos caíram e outros continuam caíndo na armadilha da palavra “Test” ao adotar  a prática Test-Driven Development (TDD). Por que armadilha? Pois a palavra “Test”, em engenharia de software, sempre nos faz pensar no primeiro momento, em atividades para garantir a qualidade (Quality Assurance) do software que estamos produzindo ou mantendo.

Para quem entendeu bem o conceito da TDD, perceberá que o mesmo não tem nada a ver com a disciplina de testes. O próprio Kent Beck, criador da TDD, uma vez falou: “TDD encoraja designs de código simples e inspira confiança”.

Na verdade, os testes unitários criados em TDD tem uma parcela de garantia de qualidade funcional, mas não é seu principal objetivo. O principal objetivo da TDD é ajudar no design dos seus códigos, promovendo a refatoração.

Nota: Vale destacar que por refatoração entende-se: “Mudar a implementação interna de um artefato de software, sem mudar seu comportamento desejado”.

Além disso, se você é um estudioso da prática TDD, já deve ter lido no site do Scott W. Ambler (caso contrário clique aqui) a seguinte frase: “What is the primary goal of TDD? Onde view is the goal of TDD is specification and not validation (Martin, Newkirk, and Kess 2003). In other words, it’s one way to think through your design before your write your functional code.”.

Percebeu? Mais uma vez: A TDD é sobre Design e não sobre Testes.

Se você ainda não está completamente convencido, dê uma olhada no próprio processo do TDD:

1. Escreva um pequeno teste de um código que ainda não exista;
2. Rode esse teste e, naturalmente, você perceberá que irá falhar;
3. Agora escreva apenas o suficiente para fazer o teste passar;
4. Quando o teste funcionar, observe o resultado do design e refatore para otimizar seu código, possível.

Repare que fiz questão de destacar em negrito/itálico o que devemos focar no final do processo TDD. É impressão minha ou não foi comentado nada sobre: “Verifique com seu especialista de domínio, analista de negócio, product owner, analista de teste ou QA, se o comportamento obtido está conforme desejado.”? É, não tem nada disso.

Com isto fica claro perceber, o porque que quando adotamos somente TDD as seguintes situações emergem durante o projeto:

• Quem desenvolve os componentes de testes unitários são os próprios desenvolvedores e não a equipe de quality assurance;
• Experimente entregar um componente de teste unitário para o analista de negócio, especialista de domínio ou product owener e espere ele dizer:  “Mas que p%$#& é essa? Não consigo entender nada.”;
• Os bugs funcionais do projeto não diminuem. Pois é comum seus testes unitários estarem todos funcionando, mas sua ferramenta de gestão de bugs está lotada de pendências funcionais;
• Normalmente, seu cliente não aceita os componentes de testes unitários com entregável da disciplina de testes.

Uma vez, em 2002, um professor meu de Engenharia de Software da UFPA falou: “Softwares sem constantes refatorações, virarão hardwares com passar do tempo”. E isto ficou na minha cabeça até hoje, como premissa em qualquer projeto que participei.

Em suma, vejo a prática TDD como uma das que compõe o alicerce para atendimento do princípio:“Contínua atenção à excelência técnica e bom design, aumenta a agilidade”, presente no Manifesto Ágil. Ou seja, use-a para promover melhorias nos seus códigos e para identificar padrões arquiteturais emergentes na sua arquitetura. Não a adote em substituição às outras práticas de garantia de qualidade, pois isto será tão negativo quanto não ter nenhum controle de qualidade em seu projeto.

Bons designs…

Melhorando seus Projetos Ágeis com Práticas do Innovation Games

Os Innovation Games são práticas alternativas, simples, objetivas e divertidas, para colaborar tanto com clientes e usuários quanto com equipes de desenvolvimento para garantir a entrega de softwares de sucesso.

Confira esse artigo na Edição 45 da Revisto MundoJ e veja como algumas dessas práticas podem ser utilizadas em um desenvolvimento ágil, de forma a melhorar o planejamento, motivação e comunicação de todos os envolvidos.

Evoluindo o design e arquitetura através das métricas do Sonar

O Design Emergente é uma prática ágil para identificar padrões comuns que são identificados, emergidos, ao longo de um desenvolvimento ágil.

Confira esse artigo na Edição 43 da Revista MundoJ e veja como podemos identificar esses padrões a partir do monitoramento contínuo da qualidade dos códigos-fonte de projetos com os indicadores e informações providas pela ferramenta Sonar.

Até a próxima e boas arquiteturas.