BT

A sua opinião é importante! Por favor preencha a pesquisa do InfoQ!

Kent Beck Sugere Pular os Testes em Projetos de Curto Prazo

| por Mark Levison  Seguidores , traduzido por Wagner R. Santos Seguir 0 Seguidores em 02 jul 2009. Tempo estimado de leitura: 5 minutos |

Para melhorar a experiência das pessoas que acessam o InfoQ Brasil, nós criamos uma série de funcionalidades que te permitem ficar pode dentro das últimas tendências e das novidades de seu interesse, sem que você seja incomodado por coisas irrelevantes. Receba e-mails periódicos e notificações sobre seus tópicos favoritos!

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?

Avalie esse artigo

Relevância
Estilo/Redação

Olá visitante

Você precisa cadastrar-se no InfoQ Brasil ou para enviar comentários. Há muitas vantagens em se cadastrar.

Obtenha o máximo da experiência do InfoQ Brasil.

Dê sua opinião

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão
Comentários da comunidade

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

HTML é permitido: a,b,br,blockquote,i,li,pre,u,ul,p

Receber mensagens dessa discussão

Dê sua opinião

Faça seu login para melhorar sua experiência com o InfoQ e ter acesso a funcionalidades exclusivas


Esqueci minha senha

Follow

Siga seus tópicos e editores favoritos

Acompanhe e seja notificados sobre as mais importantes novidades do mundo do desenvolvimento de software.

Like

Mais interação, mais personalização

Crie seu próprio feed de novidades escolhendo os tópicos e pessoas que você gostaria de acompanhar.

Notifications

Fique por dentro das novidades!

Configure as notificações e acompanhe as novidades relacionada a tópicos, conteúdos e pessoas de seu interesse

BT