Kent Beck , autor de “ Extreme Programming Explained” e “ Test Driven Development: By Example” sugere que um projeto de software, assim como golf, pode ser um jogo longo ou curto. JUnit é um exemplo de projeto longo, muitos usuários, rentabilidade estável (a $0 é triste para qualquer envolvido), onde o objetivo principal é proporcionar funcionalidades além das necessidades dos usuários.
Quando iniciei o JUnit Max, vagarosamente foi ficando claro para mim que as regras haviam mudado. A questão fundamental era (é), “Quais funcionalidades irão atrair clientes pagantes?” Por definição, esta é uma questão sem resposta. Se o JUnit (ou qualquer outro pacote livre) implementasse a funcionalidade, ninguém irá pagar pelo Max.
O sucesso no JUnit Max é definido por uma receita sustentável: quanto mais usuários pagantes, maior a receita, e/ou um grande coeficiente viral. Uma vez que, por definição, os meios de se alcançar o sucesso são desconhecidos, o que maximiza a chance de sucesso é tentar diversos experimentos e incorporar o feedback do uso atual e a adoção.
JUnit Max reporta todos os erros internos para um servidor central de modo que Kent pode ser alertado dos problemas conforme eles surgem. Estes logs de erro ajudaram a solucionar dois problemas. Para o primeiro problema ele foi capaz de reproduzir escrevendo um teste simples, e assim analisar e resolver o problema. O segundo problema foi facilmente solucionado, mas Kent estimou que ele pudesse tomar diversas horas para escrever um caso de teste para o problema. Neste caso ele somente corrigiu e atualizou a aplicação.
Kent continuou dizendo:
Quando iniciei o Max ao fim do primeiro mês eu não tinha qualquer teste automatizado. Eu fiz todos os meus testes manualmente. Após ter os primeiros usuários e voltei atrás e escrevi testes para as funcionalidades existentes. Novamente, eu acho que esta seqüência maximizou o número de experimentos válidos. Eu poderia fazer por unidade de tempo. Com pouco ou nenhum código, sem testes eu consigo iniciar mais rápido (o primeiro teste que escrevi me tomou quase uma semana). Uma vez que o primeiro bit de código se provou valoroso(de forma que poucos amigos meus pagariam por ele), testes me permitem fazer experiências com esse código com mais confiança.
Queira ou não, escrever testes automatizados requer um balanceamento de uma série de fatores. Mesmo para o Max eu escrevi um número grande de testes. Se eu posso pensar em um modo mais barato de se fazer testes, eu desenvolvo para cada funcionalidade um teste de aceite primeiro. Especialmente se não tenho certeza de como implementar a funcionalidade, escrever testes me traz boas idéias. Enquanto estou trabalhando no Max, a questão sobre se escrevo ou não um teste se resume ao fato do teste me ajudar a fazer e validar mais experimentos por unidade de tempo. Se sim, eu escrevo. Se não, deixo para lá. Estou tentando maximizar a chance de alcançar a maior receita possível com o Max. A razão em torno do investimento em design é tão complicado quanto, mas este é um tópico para um post futuro.
Ron Jeffries, autor de Extreme Programming Installed, responde: “Eu confio em você, e a respeito das outras três pessoas, para tomar boas decisões em pequenas iterações. Minha longa experiência sugere que existe uma resposta automática na curva de impacto para decisões focadas em pequenas iterações. O que faz com que a confiabilidade e a habilidade de progredir de muitos caia substancialmente.
Johannes Link, Agile Software Coach, disse: “Eu tenho visto alguns desenvolvedores que foram capazes de tomar decisões razoáveis de curto/longo prazo. Ainda estou para ver um único time, portanto; deixe a empresa tomar a decisão.”
Michael O'Brien em contraste comentou: “Um grande artigo e a decisão correta, Eu acho. É muito fácil ser pego escrevendo um código bonito e consistente, e esquecer para o que você esta escrevendo o código. Eu escrevo testes porque ele torna a escrita de código mais fácil e me dá confiança de que o código faz o que eu acho que ele deve fazer. Se escrever um teste não irá me ajudar alcançar o que quero, então eu simplesmente não faço.”
Olog Bjarnason acha que: “uma idéia relevante que Kent nos trás é o fluxo de feedback. Se nós focarmos em buscar um fluxo-por-unidade-tempo alto, nós estaremos indo na direção correta. Por exemplo, ele mencionou que adicionar funcionalidades sem testes em projetos de curto prazo maximizou o fluxo de feedback no inicio do projeto JUnitMax, uma vez que era muito complicado escrever o primeiro teste (tomou dele cerca de uma semana de trabalho). Ele teve um fluxo de feedback maior somente codificando e liberando; seus “testes vermelho” eram os seus primeiros poucos usuários e seus feedbacks.”
Guilherme Chapiewski, alertou sobre o problema de que às vezes podemos pensar que é um projeto de curto prazo mas não é. No caso de Guilherme ele decidiu iniciar um projeto sem testes como uma prova de conceito. O projeto foi para o ar e as pessoas começaram a utilizar, e rapidamente aparecem alguns bugs que não podiam ser corrigidos. No final ele concluiu que o código estava horrível e intestável. Ele jogou tudo fora e começou a fazer tudo de novo do inicio.
Kent respondeu a muitos que comentaram dizendo: “Eu concordo que confundir as práticas e os princípios levam a problemas. E que os testes levam a um design melhor. É por isto que tenho ~30 testes funcionais e ~25 testes unitários (um balanceamento esquisito porque as aplicações no Eclipse são difíceis de se testar). Eu faço para a maioria das minhas novas funcionalidades testes de aceite primeiro. Isto me ajuda a reduzir os ciclos de tempo.”
Esta idéia escala seguramente além de uma ou duas pessoas? Além de Kent Beck, existem muitas pessoas que tem o julgamento correto de deixar os testes de fora?