Sobre a discussão recente sobre TDD entre DHH, Uncle Bob, Kent Beck e Martin Fowler

gistfile1.md

Discussão iniciada no grupo tdd-no-mundo-real

Pessoal, desculpe a resposta longa mas esse assunto é muito interessante. Quem hoje em dia, pode acompanhar uma discussão entre grandes pioneiros de sua área que com certeza entrarão para a história da Engenharia de Software nos séculos seguintes? Somos muito afortunados quanto a isso.

Tenho acompanhado essas discussões pelos blogs do DHH e do Uncle Bob.

Achei que deveriam ter incluído o Uncle Bob no hangout. Como disseram que fariam outros episódios, creio que ele deve participar no próximo.

Resumindo o que tirei das opiniões deles:

###DHH:

• Defende que a aplicação de TDD como está sendo pregado atualmente pode ser prejudicial ao design e arquitetura do software, principalmente com a necessidade de isolar completamente o teste de acesso a dispositivos como o banco de dados em prol da velocidade dos testes. Levando muitos à utilização exagerada de mocks e que para ele não vale a pena o tempo gasto e complexidade que pode acrescentar.

• Outro ponto é que ele diz que a preocupação com a velocidade hoje em dia já não faz tanto sentido quanto antes, tendo o fato de que as máquinas de desenvolvimento estão bem avançadas (com uso de SSD por exemplo) com testes rodando acessando banco de dados.

• É lógico que para isso temos levar em consideração que o Rails utiliza fortemente o padrão arquitetural Active Record [PoEAA] em que as classes de domínio mapeam diretamente tabelas no banco de dados e possuem a lógica de acesso a dados ligadas a elas.

• Disse também que prefere a abordagem de programar primeiro e olhando o design, criar os testes.

• Não gosta muito da idéia de TDD ser relacionado a profissionalismo.

###Kent Beck:

• Nos recontou a estória de como surgiu a idéia de escrever testes primeiro para depois escrever a funcionalidade que o valida, saiu de um livro de programação do pai que leu quando criança.

• Disse que por causa da sua forma de pensar, para ele é mais natural escrever testes primeiro antes de escrever a solução. Pois assim consegue quebrar o problema em problemas menores e resolvê-los com mais facilidade.

• Ficou surpreso ao ouvir de algumas equipes que alegam que o TDD estava tornando o refactoring mais difícil, e quando olhou o código viu uma exagerada utilização de mocks e indireção (mocks que retornavam mocks que retornavam mocks), aumentando a dependência dos testes à implementação.

###Martin Fowler:

• Lembrou ao Kent na época que trabalharam juntos e da formulação das práticas do que viria a se tornar o XP, que nem sempre criavam testes primeiro, mas que o Kent na verdade frisava que as estórias só podiam estar prontas se os testes estivessem criados e rodando.

• Frisou que não é muito fã de mocks, apesar de respeitar que utiliza com sucesso, mas que acha que o fundamental da utilização do TDD na opinião dele é ter um sistema auto testável, e que isso seja repetível, de modo a dar confiança e permitir refactoring.

###Uncle Bob:

• Defende a forma do TDD com os 3 passos (Test - Code - Refactor) e a utilização do acrônimo FIRST (Fast, Independent, Repeatable, Sef-checking, Timely).

• Defende a questão do TDD ser relacionado ao profissionalismo, mas reconheceu recentemente vários colegas (incluindo o DHH) que não partilham de suas opiniões e sem dúvida são profissionais de enorme valor. Mas diz para olharmos para o futuro em relação a isso.

• É da opinião de que testes devem ser completamente isolados de detalhes como acesso a banco de dados, arquivos flat ou qualquer outro dispositivos, adiando o mais tardar possível essas decisões arquiteturais.

• Sobre a discussão de mocks, diz que quando não há mocks, os testes ficam lentos e erros ou situações excepcionais ficam difíceis de reproduzir. Quando existem muitos mocks, fica complexo demais e acoplado à implementação (como já constatado pelos outros). Então, como heurística, o ideal é um meio termo, que ele fala de mocks nas "fronteiras arquiteturais", separando: banco de dados, servidor de aplicação, serviços de terceiros e não utilizando "dentro" das fronteiras.

• Outra coisa interessante é que o Uncle Bob é contra a utilização (ou a utilização exagerada) de frameworks de mocks, pois ele acha que utilizando nas fronteiras, não há necessidade pois deveriam ser abstrações simples. Assim como escrevendo seus próprios mocks você tem total controle sobre nomenclatura e não precisa aprender uma nova "linguagem" (do framework de mocks).

###Todos: Testes automatizados são essenciais!

Por favor sintam-se a vontade de me corrigir caso tenha entendido alguma coisa errada.

Um abraço

links:

https://plus.google.com/events/ci2g23mk0lh9too9bgbp3rbut0k

http://david.heinemeierhansson.com/2014/tdd-is-dead-long-live-testing.html

http://blog.8thlight.com/uncle-bob/2014/04/25/MonogamousTDD.html

http://david.heinemeierhansson.com/2014/test-induced-design-damage.html

http://david.heinemeierhansson.com/2014/slow-database-test-fallacy.html

http://blog.8thlight.com/uncle-bob/2014/04/30/When-tdd-does-not-work.html

http://blog.8thlight.com/uncle-bob/2014/05/01/Design-Damage.html

http://blog.8thlight.com/uncle-bob/2014/05/02/ProfessionalismAndTDD.html