Professor Pardal e Testes

[le-silva]

Saudações!!!

Que programador nunca teve uma daquelas idéias a la Professor Pardal,
de fazer um framework, uma API, um XPTO da vida, e não começou a
implementar freneticamente logo em seguida? Acho que todos nós já
passamos por esses momentos em que a lampada acende sobre a nossa
cabeça e disparamos a programar.

Geralmente, quando isso acontece comigo, eu começo a programar e não
me importo muito em dirigir esse desenvolvimento por testes -- ainda
que eu saiba que sob muitos aspectos testes são sobre design -- e só
os escrevo ao finalizar uma implementação básica do meu insight; e daí
por diante, sim, os escrevo antes de implementar cada nova
funcionalidade.

A minha questão é: O quanto isso também acontece com vocês? Como vocês
costumam tratar esses momentos Professor Pardal?

Eu tenho tentado me policiar quando a isso, de maneira que, quando o
insight chega, tento logo começar a escrever specs da minha idéia,
para depois começar a implementá-la de fato. Mas confesso que nem
sempre é o que acontece. =$

O que vocês pensam [e fazem] a respeito?

[Lucas Catón]

Bom, o meu caso não tem muito a ver com testes, mas eu lembro que uma vez estava jogando um daqueles jogos estilo Sudobox (um puzzle onde você controla um personagem que tem que empurrar alguns blocos em determinados lugares) e não consegui passar de uma fase. Após algumas tentativas, veio o "momento Pardal" e eu criei uma app onde você informava uma matriz e ela ia testando todas as possibilidades até achar uma que revelasse a solução daquela determinada fase e retornava um "log" do que a app fez pra vencer.

Hehe, momento doido mesmo... Mas eu não acabei e acabou surgindo um problema pra eu resolver e pensei: "depois eu termino isso". Já faz mais de um ano e eu até agora não terminei (e talvez nunca o faça, rs).


Lucas Catón
Software Developer
http://www.lucascaton.com.br/
(12) 8132-1380

2009/7/8 le-silva <leand...@gmail.com>

[Ronaldo Ferraz]

Eu sigo mais ou menos o mesmo processo: nunca me importo com testes
enquanto não tiver uma sensação de que o que estou pensando faz
sentido. Isso geralmente envolve provas de conceitos bem rápidas para
ter uma idéia geral de como a interface/contrato/classes ficarão.
Essas provas de conceito são, na maioria, throw-away code que nem
chega a executar completamente de qualquer maneira.

Depois disso, tento seguir rigorosamente com testes quando o que estou
fazendo dá para testar de maneira comum. Se não, crio uns scripts
mesmo para sanitização.

TDD faz sentido mas muita gente acha que é só sair escrevendo testes
loucamente e que o design vai surgir disso. Se não se sabe para onde
se vai, não há TDD que funcione. ;)

Abraços,

R.

2009/7/8 le-silva <leand...@gmail.com>:

[Rodrigo Kumpera]

2009/7/8 le-silva <leand...@gmail.com>

Eu costumo fazer um spike, que pode levar até uma semana inteira, até ter uma prova
de conceito. Nessa etapa não me preocupo muito com testes e não necessariamente
termino com um demo do software em si.

Depois disso, se eu ver que a idéia é interessante, passo a me focar em escrever software
direito, com testes. Se os fontes do spike vão ser usados ou não é outra história.

O número de spikes pode variar, que é a situação da minha atual idéia, um compilador de HLSL,
no primeiro produzir um decompilador, no segundo produzi uma ferramenta para automação
de testes dos shaders e atualmente estou tentando arrumar tempo p/ por tudo junto e começar
a avançar com ele. O ruim de múltiplos spikes é que mais de um desmotiva um pouco.

[le-silva]

> Depois disso, se eu ver que a idéia é interessante, passo a me focar em
> escrever software
> direito, com testes. Se os fontes do spike vão ser usados ou não é outra
> história.

Concordo contigo. Porque muitas vezes o que você codifica fruto desses
insights, num primeiro momento, é só pra chegar ao ponto de organizar
as suas idéias e saber se vale a pena prosseguir ou não -- pra não
perder tempo com o que não interessa no momento.

> TDD faz sentido mas muita gente acha que é só sair escrevendo testes
> loucamente e que o design vai surgir disso. Se não se sabe para onde
> se vai, não há TDD que funcione. ;)

Isso faz todo sentido pra mim. Design sem uma idéia clara é pura arte
abstrata. =D


On 8 jul, 18:14, Rodrigo Kumpera <kump...@gmail.com> wrote:
> 2009/7/8 le-silva <leandrod...@gmail.com>

[Marco Gomes]

Eu não sou um programador experiente, nunca fiz um TDD na vida e nem
saberia por onde começar se precisasse (pensando bem, acho que saberia
sim, Google). Mas acho que posso constribuir na discussão.

Isso acontece bastante comigo. Normalmente no fim da noite tenho
idéias que considero interessantes pra serem implementadas, nesses
momentos eu seto uma deadline, normalmente 8am, e faço o (im)possível
pra ter algo usável até lá. Bem Getting Real.

E por algo usável, estou dizendo usável por "alguém". Pode ser que dê
pau no IE, que não aceite feeds em UTF-8, que não funcione para texto
em português, que só mande emails pra Gmail, sei lá, pode ter vários
bugs, mas 8am eu me forço a parar e repensar o projeto.

Gilberto Jr, CEO da Amanaiê, inspirado em meus relatos deu nome pra
esse processo: Insôniaware :)
<http://startupi.com.br/2008/le-parcours-du-combatant-marco-gomes/>

Algumas coisas que surgiram assim
<http://marcogomes.com/wallpapr/en/>
<http://boo-box.com/site/setup/signup#publishers>
<http://writingabout.appspot.com/>
<http://myadbird.appspot.com/>
<http://marcogomes.com/wallpapr/iphone/>

Texto que escrevi sobre o tema
<http://marcogomes.com/blog/2009/esse-projeto-vale-a-pena>
O mesmo texto editado para o Webinsider
<http://webinsider.uol.com.br/index.php/2009/03/04/um-criterio-para-saber-se-o-meu-projeto-vale-a-pena/
>



Marco Gomes
e...@marcogomes.com
http://marcogomes.com
http://twitter.com/marcogomes

Please don't print this e-mail
Evite imprimir este e-mail

[Luiz Rocha]

> A minha questão é: O quanto isso também acontece com vocês? Como vocês
> costumam tratar esses momentos Professor Pardal?

Acontece sim, e normalmente eu sequer lembro de testes, só me
preocupo em curtir o momento. :-)

Eventualmente, se o momento resultar em alguma coisa significativa,
que eu pretendo tocar para frente e manter, ai sim, testes entram no
processo, para suportar design, refatorações e tudo mais.

Como eu normalmente descarto ou deixo de lado as coisas que surgem
nesses momentos (e outras também), quase sempre a fase em que os
testes entram no flow nem chega...

--
Luiz Rocha