Pragmatismo e TDD

Anteontem, 05 de Março de 2013, Uncle Bob Martin, um dos principais defensores do desenvolvimento guiado por testes (TDD), fez uma crítica ao modo como são vistas as startups, jovens empresas que se aventuram, ousam, e se arriscam na busca do sucesso através da criação de softwares inovadores. 

Como resposta, alguns leitores tacharam o autor de ser muito dogmático a respeito da prática de TDD. E quem o conhece sabe que há alguma verdade nisso.

No dia seguinte, Uncle Bob publicou uma resposta onde apresentou o seu ponto de vista com relação ao pragmatismo vs dogmatismo no que se refere à prática de TDD, apontando situações em que ele é pragmático e não utiliza a técnica.

Segue abaixo, traduzido para nosso idioma:

Então, quando eu não pratico TDD?

• Não escrevo testes para getters e setters. Fazer isso normalmente é besteira. Tais getters e setters serão indiretamente testados por testes de outros métodos; então não há porquê testá-los diretamente.
• Não escrevo testes para variáveis membros. Elas também serão testadas indiretamente.
• Não escrevo testes para funções de uma só linha ou funções que são obviamente triviais. Novamente, elas serão testadas indiretamente.
• Não escrevo testes para GUIs. GUIs necessitam ajustes. Você tem que acertá-las no lugar alterando tamanho de fonte aqui, valores RGB ali, uma posição XY aqui, a largura de um campo ali. Fazer isso com testes primeiro é estupidez e perda de tempo.
• No entanto, me certifico que qualquer processamento relevante no código da GUI seja removido para módulos que sejam testáveis. Não permito que código relevante passe sem testes. Portanto meus códigos de GUI são pouco mais que colas e fios que enfiam os dados no seu lugar na tela (Veja artigos sobre MVVM e Model View Presenter).
• Em geral não escrevo testes para nenhum código que eu tenha que ajustar no lugar por tentativa e erro. Mas separo o código "ajustável" do código que estou mais certo de que escreverei testes.
• Ocasionalmente, ajusto código no lugar e então escrevo os testes posteriormente.
• Também ocasionalmente removo código "ajustado" e o reescrevo com testes primeiro.
• Qual abordagem escolher é uma questão de julgamento.
• Alguns meses atrás escrevi um programa inteiro de 100 linhas sem nenhum teste.
• O programa era para uma única execução. Seria usado uma vez e então descartado. (Era para um efeito especial em um de meus vídeos).
• O programa era todo relacionado à tela. Em essência, era um aplicativo GUI puro. Sendo assim eu tive que ajustar a coisa toda no lugar.
• Escrevi em Clojure, e portanto tinha REPL! Pude executar o programa à medida em que crescia a partir da REPL, e pude ver os resultados de cada linha de código que escrevia instantaneamente. Isso não era TDD, isso era EDD (Eye Driven Development).
• Normalmente não escrevo testes para frameworks, bancos de dados, web-servers, ou outra ferramenta de terceiros que supõe-se funciona. Crio mocks para essas coisas e testo o meu código, não o deles.

• Claro que as vezes testo códigos de terceiros se:
• Acredito que tenha defeitos.

• Os resultados são rápidos e previsíveis o bastante a ponto de criar um mock ser um exagero.

Não é tudo dogma.

Essa lista não está completa. Estou certo de que pensarei em outras vezes que não escrevi testes; mas o espirito dessa lista deve estar evidente. Pragmatismo entra em jogo quando fazemos TDD. Não é apenas dogma.

Entretanto, respeito o dogma; há uma razão para isso. Pragmatismo pode as vezes se sobresair; mas: Não escreverei nenhum código de produção relevante sem fazer todo esforço para usar TDD.

Uncle Bob Martin

Qual é o seu produto de software?

Para muitas empresas, um produto de software é visto como o resultado de um projeto de software, restrito a escopo, prazo e custo predefinidos.

Pensa-se em produto de software como o conjunto de arquivos a serem instalados nos computadores (servidores, desktops, dispositivos, etc) em que o software será utilizado pelo cliente.

Uma vez que tal conjunto de arquivos satisfaça aos requisitos contratados pelo cliente, considera-se que o produto de software apresenta a qualidade esperada.

Okay, mas onde está o problema nisso?

Requisitos de software, e principalmente requisitos informados pelos clientes, nem sempre especificam critérios de qualidade interna, e quando o fazem, fazem de maneira bem superficial, deixando a interpretação a cargo de quem for desenvolver e avaliar o cumprimento de tais requisitos.

À medida que o produto de software vai sendo utilizado, solicitações de mudança começam a surgir, regras são alteradas, novas funcionalidades são incluídas, e uma nova versão do produto de software é distribuída a cada conjunto de alterações negociadas.

Novamente, uma vez que os requisitos apresentados são satisfeitos, a nova versão é aceita e a vida segue.

Eventualmente, algo para de funcionar. "Quem mexeu nisso?", "Isso funcionava na última vez que usei.", "E quando foi isso?", "Não me lembro, mas funcionava."

E ai começa o inferno para o programador. Gerentes cobrando resultados e o desaparecimento dos bugs, prazos apertados ou inexistentes, cliente reclamando, correções feitas sem a devida atenção, novos defeitos sendo introduzidos. Você já deve ter entendido do que estou falando.

Mas o que uma coisa tem a ver com a outra? Atender aos requisitos do cliente e ter o software aprovado com base no cumprimento de tais requisitos é o que causa esse tipo de problema? Não. Mas atender aos requisitos do cliente não deve ser o único objetivo. E ver o produto de software como um conjunto de arquivos executáveis que satisfaça a esses requisitos também não é o mais adequado. Para se evitar esse tipo de "problema inesperado", é necessário investir na qualidade interna do produto, ou seja, naquilo que o cliente não vê, não avalia, não aprova, e que deve ser considerado o verdadeiro produto de software a ser produzido e mantido: o seu código fonte.

A única forma de se evitar que erros sejam introduzidos no software sempre que funcionalidades forem alteradas ou introduzidas é garantir que o código fonte seja mantido em um alto nível de qualidade, seguindo boas práticas de desenvolvimento, utilizando técnicas e disciplinas desenvolvidas especificamente para tal finalidade.

Falta de qualidade interna normalmente não prejudica as primeiras versões do software, não prejudica a sua aprovação, não bloqueia seu pagamento. E com isso investimentos em qualidade interna acabam sendo ignorados, vistos como algo desnecessário, dispensável.

Entregar o software dentro do escopo, prazo e custo é importante, mas manter a saúde do software ao longo de sua vida também é. Lembre-se, o seu verdadeiro produto de software não são os binários entregues, isso se consegue gerar novamente com uma compilação. O seu verdadeiro produto de software são os seus códigos fonte. Invista na qualidade deles, e o resto virá naturalmente.

Apresentação

Boa tarde a todos,

Meu nome é Rafael Romão, sou desenvolvedor de software e fotógrafo de natureza, nas horas vagas.

Trabalho desde os 14 anos, hoje tenho 31, e desenvolvo software desde os 17. Iniciei desenvolvendo pequenos programas para a empresa onde trabalhava, uma distribuidora de materiais de construção. Posteriormente passei a "fazer programas para viver". Desenvolvi softwares para a área notarial (cartórios), laboratórios de imunohematologia, hemocentros e atualmente operação de redes de distribuição de energia elétrica.

Programei em Delphi por cerca de 9 anos e em C# por pelo menos uns 6, me especializando no desenvolvimento de aplicações desktop, particularmente WPF.

Há cerca de 6 anos tenho direcionado minha carreira para arquitetura de software e há cerca de 2 anos para metodologias ágeis.

Sou licenciado em Matemática, pós-graduado em Analise de Sistemas e atualmente curso pós-graduação em Estratégias em Arquitetura de Software.

Há anos acompanho blogs de diversos desenvolvedores, e cresci muito em minha carreira com o que aprendi com eles. Até tentei manter um blog uma vez, mas acabei desanimando.

Hoje a realidade é diferente, e sinto que devo reabrir esse espaço.