"It's OK Not to Write Unit Tests" (e a resposta do Uncle Bob)

[Vinicius Quaiato]

Chris Ashton, funcionário da MS, escreveu o seguinte artigo em seu blog:

http://blogs.msdn.com/cashto/archive/2009/03/31/it-s-ok-not-to-write-unit-tests.aspx

Algumas pessoas pediram que Uncle Bob comentasse sobre o assunto.

E ele o fez aqui:

http://blog.objectmentor.com/articles/2009/11/05/its-ok-not-to-write-unit-tests-not

Acho que vale à pena dar uma lida tanto no post quanto na resposta do Uncle Bob.

O que vocês acham dos argumentos de ambos?

Att,

Vinicius Quaiato.

www.viniciusquaiato.com

[Leo D]

Uma coisa que penso a respeito de teste de unidade é que eles fazem mais sentido quando os programadores são menos experientes. A adoção tende a subir o nível de um time iniciante ou mediano. Para programadores veteranos, acostumados com o domínio da aplicação e familiares com a plataforma, a adoção de alta porcentagem de cobertura de código vai diminuir a produtividade deles - sem ganho em contra partida de grandes benefícios.

Se o desenvolvedor escreve um teste de unidade para detectar um bug que levaria 5 minutos para ser corrigido, e ele leva 20 minutos escrevendo o teste, ele faz um mal negócio, e consequentemente gerou um custo maior para o projeto.

[]s

[Vinicius Quaiato]

Como é que se sabe que o bug levaria 5 minutos para ser corrigido se ele ainda nem apareceu?

E mesmo que o teste tenha levado 20min. O teste não irá garantir que esse bug nunca mais volte a acontecer?! Isso é um enorme benefício, não?!

Att,

Vinicius Quaiato.

www.viniciusquaiato.com

2009/11/5 Leo D <l...@codigofluente.com.br>

[Leo D]

Porque depende do teste e do feeling/experiência do programador.

Por exemplo, do seu blog:

public void Depositar(decimal valorDoDeposito)
{
    this.SaldoAtual += valorDoDeposito;
}

[TestMethod]
public void Deve_Realizar_Deposito_de_10_Em_Conta_Com_Saldo_10_E_Saldo_Deve_Ficar_20()
{
    var conta = new ContaBancaria(10);
    conta.Depositar(10);
 
    Assert.AreEqual(20, conta.SaldoAtual);
}

A única coisa que você está testando, nesse caso, é o .NET Framework. Não há nada para ser testado aqui que mereça um teste de unidade. Sim, entendo que o seu post é didático, não é um exemplo do mundo real. Mas o que quero dizer é que, na minha opinião, teste de unidade cai no lugar comum do "depende".

Eu gosto para testar regras que tem entrada e saída bem definidas, com múltiplos caminhos e permutações, e que não possuem tendência de mudar. São casos em que os testes de unidade ajudam. Em outros eles podem dar um retorno sobre o investimento negativo - eu costumo ficar na defensiva quando escuto uma empresa dizer que vai elevar a qualidade do software mirando em 90% de cobertura de código com testes de unidade. Talvez melhore algo, mas o preço disso será altíssimo, com a produtividade que vai ser perdida com os testes ("que não testam nada significativo") que vão quebrar, quando você precisar refatorar ou alterar o código, principalmente nas áreas do sistema que são voláteis e sujeitas a mudança.

[]ss

[Vinicius Quaiato]

Você pegou um exemplo totalmente "acadêmico". Que no seu contexto serve apenas para mostrar como realizar TDD...

Não dá nem pra entrar no mérito da complexidade...

2009/11/5 Leo D <l...@codigofluente.com.br>

[Rafael Mueller]

2009/11/5 Leo D <l...@codigofluente.com.br>

Uma coisa que penso a respeito de teste de unidade é que eles fazem mais sentido quando os programadores são menos experientes.

A maior corrente à favor de TDD vem de desenvolvedores muito experientes (Uncle Bob, Martin Fowler, desenvolvedores no google, yahoo, thoughtworks), então não concordo com a idéia de que testes de unidade fazer mais sentido em menos experiêntes.

Acho que devs menos experientes se apegam mais na parte de testes do TDD, devs experientes conseguem ver a melhoria no design causada pelo TDD.

[Diego Caxito]

Bom, estudando a técnica (TDD), você quebra muitos, mas muitos paradigmas de desenvolvimento e design de aplicações.

Dentro do blog do autor que originou a discussão gostaria de destacar aqui um trecho da apresentação, escrita por ele, sobre quem ele é e o que faz:

"I work on Outlook Mobile, specifically Messaging -- the email / SMS client for Pocket PCs and Smartphones.  Although it's one of the most visible and important apps on Windows Mobile, it's actually fairly prosaic work ... working on various features now and then, but mostly just a lot of bugfixing.  Still, the challenges are there, not unlike in most software engineering projects."

Ele mesmo já se definiu e através de seu post já sabemos o porque dele trabalhar duro em seus “just a lot of bugfixing”. (acredito que chegamos fácil à conclusão do "porque")

Suas declarações acabam mostrando que, apesar de tentar, não foram boas suas experiências com TDD e a aplicação da técnica, talvez por uma errada inserção neste mundo ou uma errada abordagem quanto a adoção da mesma.

A conclusão a que chego e o que me leva a regredir a pensamentos, é do quão importante e deve ser cuidadoso o caminho de adoção de novas técnicas junto à equipe e preparar a mesma para novos desafios, pensando não apenas no início e empolgação da adoção, mas lembrando que qualquer nova abordagem deve haver um trabalho para que a mesma se perpetue de maneira correta ou em contínua melhoria.

Abraço.

2009/11/5 Rafael Mueller <muell...@gmail.com>

--
Diego Caxito

[Marcelo Zeferino]

Acrescentando, TDD não é uma coisa lá tão simples a ponto de desenvolvedores menos experientes conseguirem seguir facilmente, com sucesso, essa abordagem.

IMHO, exige certo grau de experiência e conhecimento de algumas técnicas...

Atualmente não tenho conseguido ver a coisa realmente funcionando sem test first, seja TDD ou BDD. Que segurança eu teria em mudar qualquer coisa em meu código se não tivesse um mecanismo que me diga que, mesmo depois de mudanças críticas, meu código ainda funciona como o esperado?

A[]´s

Marcelo Zeferino

2009/11/5 Rafael Mueller <muell...@gmail.com>

[Eduardo Miranda]

Uma coisa que penso a respeito de teste de unidade é que eles fazem mais sentido quando os programadores são menos experientes. A adoção tende a subir o nível de um time iniciante ou mediano. Para programadores veteranos, acostumados com o domínio da aplicação e familiares com a plataforma, a adoção de alta porcentagem de cobertura de código vai diminuir a produtividade deles - sem ganho em contra partida de grandes benefícios.

 

 Este pensamento, que um desenvolvedor é capaz de escrever 10, 100, 1000 linhas de código sem erro, é extremamente prejudicial. É isto que faz um desenvolvedor simplesmente não testar o código que escreve, seja com testes unitários automáticos ou manualmente.

 

A verdade é que nenhum desenvolvedor é capaz de escrever código sem bug. Admitir isto é sinal de maturidade e não de inexperiência.

 

 

 

2009/11/5 Leo D <l...@codigofluente.com.br>

[Vinicius Quaiato]

Um dos pontos que me chamou a atenção é este:

"Agile dogma says that tests should be fine grained, but really, what's the point? Debugging is easy, at least in comparison to writing all those tedious tests. If you think about it, all you really need is something that alerts you that something, somewhere, has gone wrong—a “tripwire” test, so to speak."

Debugging is easy...

Caramba, Debugar é complicado, chato, lento... Imagine... Testar a camada mais baixa de negócio, na décima etapa de um processo longo, tudo passando por todas as telas da interface gráfica... Debugging é complicado, lento, desperdício de tempo.

Att,

Vinicius Quaiato.

www.viniciusquaiato.com 

2009/11/5 Eduardo Miranda <dud...@gmail.com>

[Rafael Noronha]

Eu acho bastante sensato o posicionamento do autor.

É o que eu venho defendendo ultimamente: avalie o custo de tudo.

Testar é custoso, ponto.

Não testar será ainda mais custoso?
A resposta errada é sim.
A resposta certa é talvez.

Escrever uma porrada de testes unitários - mesmo tendo uma boa noção
do que você está fazendo, pode sim ser pior do que não escrever nenhum
deles.

Escreva um código limpo, expressivo e apoiado em boas técnicas.
Especifique e garanta o funcionamento de negócio com testes de
aceitação e integração.

TDD não é a única arma para se chegar a um bom design, documentar o
código ou prevenir bugs.

E nem sempre deixar de testar é faltar com profissionalismo.
Isso não passa de uma excelente jogada de marketing do Uncle Bob.

[Vinicius Quaiato]

@Rafael

Eu acho bastante sensato o posicionamento do autor.

Por que?

 

Não testar será ainda mais custoso?
A resposta errada é sim.
A resposta certa é talvez.

Eu diria que a resposta é: Não ter testes que garantam aquilo é perigoso, não te dá garantias de futuras modificações! Logo, você perderá mais tempo em "testes do macaco".

 

Escrever uma porrada de testes unitários - mesmo tendo uma boa noção
do que você está fazendo, pode sim ser pior do que não escrever nenhum
deles.

Por que podem ser pior? 

 

Escreva um código limpo, expressivo e apoiado em boas técnicas.
Especifique e garanta o funcionamento de negócio com testes de
aceitação e integração.

Existem bugs que não são vistos a olho nu...

 

TDD não é a única arma para se chegar a um bom design, documentar o
código ou prevenir bugs.

Eu considero que os testes que ali estão garantem a não criação de bugs no futuro. Mantenha-os verde e tudo está ok. Evolua o código, evolua os testes e tudo está ok. Altere um classe, mantenha os testes verdes e tudo está ok.

 

E nem sempre deixar de testar é faltar com profissionalismo.

Não?!

Att,

Vinicius Quaiato.

www.viniciusquaiato.com

[Alexandre Valente]

Oi,

Sou mais um do "contra". No meu caso especificamente, eu concordo completamente com o autor. Testar (bem) é caro, e com certeza diminuiu minha produtividade. (Já imagino a facção fundamentalista TDD preparando para o fuzilamento! rsrs). E sim, conheço TDD, já vi pessoas que fazem isto muito bem trabalhando e eu mesmo já usei, da maneira prevista, em vários cenários para avaliar. E minha conclusão é a mesma do autor, em vários cenários isto pode se mostrar inviavelmente caro.

Significa que TDD é ruim? Óbvio que não, estou falando do meu caso em específico.... Claro que em equipes onde várias pessoas, de níveis diferentes mexem no código e em uma diversidade de outros cenários, com cerrteza TDD é muito útil. Mas eu vou contra a opinião de vários xiitas de que TDD "is the only true way"... :-). Acredito que em times pequenos, só de seniores, a utilização de TDD vai aumentar custo sem contrapartida. E aí o seu uso tem que ser ponderado, pode ser que valha a pena, pode ser que não valha... Nos meus projetos atuais, com certeza não vale.

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/5 Vinicius Quaiato <vinicius...@gmail.com>

[Juan Pedro A. Lopes]

Escreva um código limpo, expressivo e apoiado em boas técnicas.
Especifique e garanta o funcionamento de negócio com testes de
aceitação e integração.

Escreva um teste limpo, expressivo e apoiado em boas técnicas e você vai perceber que escrever um código desse jeito nem é tão importante. O simples fato de criar testes unitários facilitará seu caminho em tornar aquele código independente o suficiente para ser mudado assim que preciso.

Sério, imagine um processo muito grande. Imagine esse processo todo descrito num único método sem comentários (mas que funciona). Você, bom programador, pensa "Putz, isso está errado. Deixe-me quebrar esse método em métodos menores". Nesse ponto, você assume a responsabilidade de fazer o método continuar funcionando, e é uma senhora responsabilidade.

Agora, imagine que existem dezenas de métodos que especificam os caminhos mais críticos desse processo. Esses são os testes unitários, exercendo sua segunda melhor função: documentar. Nesse ponto, você passa a entender o que o processo deveria fazer, e sente-se muito mais confiante para mudar o código para melhor, apertar o "Run" e ver que os testes continuam passando. Sem melhor design, sem comentários inline. Não que coesão não seja importante, mas toda a coesão realmente necessária pode ser aquela obtida pelo que os testes unitários lhe obriga.

Testes unitários diminuem a velocidade inicial de um projeto, e isso é fato que nem precisa ser comprovado. Mas a longo prazo, só quem usa da forma correta entende o quão é importante tê-los.

[Juan Pedro A. Lopes]

O mais engraçado é que TDD é uma prática mais motivadora para o desenvolvedor do que para o gerente. E o que me deixa mais triste é ver que a maior resistência é por parte dos desenvolvedores.

Talvez tenha alguma coisa a ver com a auto-confiança natural dos programadores.

--
Kind regards,
Juan Lopes

juanp...@gmail.com
con...@juanlopes.net
http://juanlopes.net
http://twitter.com/juanplopes

[Rafael Noronha]

Vinicius,

>> > Não testar será ainda mais custoso?
>> > A resposta errada é sim.
>> > A resposta certa é talvez.
>>
>> Eu diria que a resposta é: Não ter testes que garantam aquilo é perigoso,
>> não te dá garantias de futuras modificações! Logo, você perderá mais tempo
>> em "testes do macaco".

Testes unitários corretamente escritos garantem pouca coisa.
Quando um deles quebra significa que UM OBJETO deixou de se comportar
da maneira que você esperava.
Escreva testes de integração - focados nas expectativas de negócio, e
se alguma coisa quebrar durante uma manutenção, um destes testes
deverá acusar.
Você não precisa testar cada objeto isoladamente para colocar em
produção um software confiável.

>> > Escrever uma porrada de testes unitários - mesmo tendo uma boa noção
>> > do que você está fazendo, pode sim ser pior do que não escrever nenhum
>> > deles.
>>
>> Por que podem ser pior?

Pelos motivos apontados pelo Ashton.

>> > Escreva um código limpo, expressivo e apoiado em boas técnicas.
>> > Especifique e garanta o funcionamento de negócio com testes de
>> > aceitação e integração.
>>
>> Existem bugs que não são vistos a olho nu...

Eu mencionei testes de aceitação e integração, e eles são
automatizados.

>> > TDD não é a única arma para se chegar a um bom design, documentar o
>> > código ou prevenir bugs.
> >
> >Eu considero que os testes que ali estão garantem a não criação de bugs no
> >futuro. Mantenha-os verde e tudo está ok. Evolua o código, evolua os testes
> >e tudo está ok. Altere um classe, mantenha os testes verdes e tudo está ok.

Acredito que seja possível alcançar o mesmo objetivo sem testar todo o
sistema unitariamente.

>> > E nem sempre deixar de testar é faltar com profissionalismo.
> >
> >Não?!

Definitivamente não.

[Rafael Noronha]

Juan,

> > Escreva um código limpo, expressivo e apoiado em boas técnicas.
> > Especifique e garanta o funcionamento de negócio com testes de
> > aceitação e integração.
>
> Escreva um teste limpo, expressivo e apoiado em boas técnicas e você vai
> perceber que escrever um código desse jeito nem é tão importante. O simples
> fato de criar testes unitários facilitará seu caminho em tornar aquele
> código independente o suficiente para ser mudado assim que preciso.
>
> Sério, imagine um processo muito grande. Imagine esse processo todo descrito
> num único método sem comentários (mas que funciona). Você, bom programador,
> pensa "Putz, isso está errado. Deixe-me quebrar esse método em métodos
> menores". Nesse ponto, você assume a responsabilidade de fazer o método
> continuar funcionando, e é uma senhora responsabilidade.
>

Se o meu código é bem estruturado, eu não preciso testar cada
pedacinho dele, já que a responsabilidade de cada pedacinho é
evidente. Testes de integração serão o suficiente, já que testar o
micro não gera valor significativo.

> Agora, imagine que existem dezenas de métodos que especificam os caminhos
> mais críticos desse processo. Esses são os testes unitários, exercendo sua
> segunda melhor função: documentar. Nesse ponto, você passa a entender o que
> o processo deveria fazer, e sente-se muito mais confiante para mudar o
> código para melhor, apertar o "Run" e ver que os testes continuam passando.
> Sem melhor design, sem comentários inline. Não que coesão não seja
> importante, mas toda a coesão realmente necessária pode ser aquela obtida
> pelo que os testes unitários lhe obriga.

Me parece que a documentação que você gera através de seus testes
unitários, eu gero diretamente no meu código em produção, com o
capricho que ao seu ver não é tão importante.

Além disto os testes de integração são a forma mais perfeita de
documentação.
Já viu o que é possível fazer com o Fitnesse?

[Vinicius Quaiato]

@Alexandre,
Por que você diz que testar é caro, ou praticar TDD é caro? Não entendo como isso pode ser mais caro.
Na minha singela utilização de TDD tenho percebido que é mais rápido, prático, e garante muito mais do que simplesmente o teste do macaco.

Para mim caro é perder tempo, e não vejo perda de tempo com TDD.
Além do TDD ser rápido e prático, os testes permanecem lá, ao contrário dos testes do macaco.

Att,
Vinicius Quaiato.
www.viniciusquaiato.com

2009/11/5 Alexandre Valente <alexandre...@gmail.com>

[Vinicius Quaiato]

Rafael ,

Testes unitários corretamente escritos garantem pouca coisa.

???

Quando um deles quebra significa que UM OBJETO deixou de se comportar
da maneira que você esperava.
Escreva testes de integração - focados nas expectativas de negócio, e
se alguma coisa quebrar durante uma manutenção, um destes testes
deverá acusar.

Ué, e o que é que se faz nos testes não é isso? Objetos interagem e trocam informações, e assim realizam algo. E os testes garantem que a necessidade de negócio é atingida.

Att,
Vinicius Quaiato.
www.viniciusquaiato.com

[Alexandre Valente]

Oi Vinicius,

Como eu falei, este é o meu caso. Com certeza não deve ser o de outros. Mas no meu caso, quando eu vou fazer uma rotina com TDD, o tempo é maior em qualquer cenário. Se a rotina é simples, não faz sentido fazer o teste pois eu consigo debugar muito mais rapidamente do que se eu escrever um teste antes pra pegar todos os possiveis erros (e não, não tenho probelmas no futuro, como falei minha equipe é pequena e só de seniores, assim são todos capazes de fazer refactors sem quebrar muita coisa ... e mesmo o custo de eventuais quebras é menor do que o de TDD sem si).

Se a rotina é complexa, projetar o teste antes leva tempo. Além de eu ter que pensar em quais casos eu tenho que montar pra tentar quebrar o código (os casos simples obviamente não servem pra quase nada), como o design é orientado ao teste bem sucedido, muitas vezes eu gasto um tempo grande refatorando a rotina em conforme ela vai sendo criada pra atender o teste. Quando eu parto pra rotina primeiro, em uma abordagem estruturada, o design quase sempre é correto da primeira vez. Ou seja, qto mais complexa a rotina, mais rápido eu faço sem TDD, simples assim.

Isto sem falar em treinamento de equipe. É muito raro encontrar alguém que seja produtivo usando TDD (eu só conheci um em toda minha carreira). E treinar alguem pra usar TDD é muito, muito caro.

Então, como falei, no meu caso TDD é sempre ruim, do aspecto de produtividade (e na qualidade, o que produzimos hoje é bom o suficiente). Claro que eu uso testes em alguns cenários, quando a rotina é complexa, quando ela é muito crítica (e é importante ter um teste unitário), como ferramenta de debug em situações complexas. Mas TDD por TDD, nos meus projetos atuais eu não acho que valha a pena.

[Eduardo Miranda]

Se a rotina é simples, não faz sentido fazer o teste pois eu consigo debugar muito mais rapidamente do que se eu escrever um teste antes pra pegar todos os possiveis erros

 

Para debugar o método é preciso exercitar este método em um ou mais cenários, de alguma forma vc chama este método, então de alguma forma vc já está escrevendo um "mini" teste e pensando e executando cenários possíveis e prováveis.

 

Entendi correto o que vc faz?

 

Caso contrário vc não está exercitando o código, apenas confiando na sua capacidade, como desenvolvedor, de escrever código-fonte correto, sem erros.

 

Então vc já gasta no seu dia-a-dia este tempo de escrever um teste e pensar nos cenários.

 

PS: Eu não confio na minha capacidade, esta auto-confiança já foi minada pelos anos de trabalho, bugs e cagadas. Como disse antes, admitir isto é sinal de senioriadade.

2009/11/5 Alexandre Valente <alexandre...@gmail.com>

[Alexandre Valente]

Exato, Por isto q eu falei, isto vale pra mim.... :-)

PS.: Eu confio cada vez mais na minha capacidade e na da minha equipe, cada ano de trabalho com bugs e problemas contribui para nos tornar ainda melhores no que fazemos! :-) :-).  Não que a gente não cometa erros, mas o custo de fazer software sem TDD ainda é menor do que o com TDD. :-)

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/5 Eduardo Miranda <dud...@gmail.com>

[Fabio Margarito]

Alexandre,

Tive uma experiência diferente com TDD. Sou questionador com relação a novos conceitos e técnicas, eu não aceito e prego de cara, primeiro eu testo e gero minhas opiniões. Eu não utilizava TDD e resolvi fazer um teste em uma aplicação de baixo risco(que não tinha prazo) para eu avaliar e ter uma opinião a respeito. Não achei que TDD atrasou o meu trabalho, pelo contrário, no meu caso houve ganho, pois eu não pensava em nada complexo(esta foi a parte difícil), cada teste era bem simples, e a cada refactoring eu tinha mais métodos simples e no final algo que era complexo, na realidade se dividiu em pequenas partes simples com um nível de abstração por método e classe. Mas acho, que há necessidade de maturidade do desenvolvedor, pois o design vai acontecendo durante os testes, e é necessário, na minha opinião, ter bons conhecimentos de princípios de orientação a objeto para tomar as decisões corretas.

Acho bem legal ter cobertura de código com testes, pois me deixa mais seguro para realizar alguma melhoria no meu código, e caso eu tenha introduzido qualquer tipo de bug, alguns testes irão quebrar.

Treinar uma equipe tem custo, por quebrar paradigmas, mas acho que vale a pena a longo prazo e há maneiras legais de fazer isto, como o coding dojo.

No coding dojo que fizemos, que era a solução do jogo da vida, utilizamos o TDD e foi bem legal, o que era complexo foi dividido em partes simples e o problema ia se resolvendo.

Eu gosto deste trecho do Livro do Kent Beck e concordo com ele

"Test-driven development is a set of techniques that any software engineer can follow, wich encourages simple desgins and test suites tha inspire confidence. If you are a genius, you don't need these rules. if you are a dolt, the rules won't help. For the vast majority of us in between, following these two simple rules can lead us to work much more closely to our potencial

- Write a failing automated test before you write any code
- Remove duplication.
"

[]'s
Fabio Margarito

2009/11/5 Alexandre Valente <alexandre...@gmail.com>

[Alexandre Valente]

Não duvido Fábio. Como falei, já conheci gente que usa com sucesso. Não conheço muitas estatísticas de produtividade (conheço um pessoal de uma grande empresa de mídia que usa TDD direto, porém como o cliente no caso é a própria empresa, os resultados da unidade de negócio de desenvolvimento ficam complexos de serem calculados). Mas não ficaria surpreso se em algum cenário, o resultado se pagasse. O que eu disse é que no meu caso, todas as minhas tentativas geraram um custo bem superior. 

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/5 Fabio Margarito <fabioma...@gmail.com>

[Fabio Margarito]

Tranquilo, entendi sua posição, só coloquei a minha experiência.

abs

2009/11/5 Alexandre Valente <alexandre...@gmail.com>

[Vinicius Quaiato]

Oi Alexandre,

Não vejo que o tempo de dev. com TDD seja maior, não vejo mesmo. Como já foi dito, se você não escreve testes, acredita que o código esteja pronto. De fato em algumas situações ele estará mesmo, mas na grande maioria das aplicações comerciais, com regras de negócios complexas (sempre existem), com objetos que interagem entre si gerando outros objetos e desencadeando comportamentos, etc, o debug é deveras lento e complicado, principalmente em se tratando de aplicações web, web services e services.
O tempo de debug é muito superior ao tempo de um teste sendo executado.

Entendo que este seja o seu caso, e talvez você e sua equipe se encaixem no que o Kent Beck diz ser um "genius", e isso é realmente muito bom.
No entanto não acho justo você dizer que TDD eleva o custo e o tempo de desenvolvimento, ainda que isso se aplique à sua equipe.

Se sua equipe não consegue escrever testes simples, de baixa granularidade e dependência, talvez tenha algo errado aí, mas não quero questionar suas capacidades, lendo seu blog vejo que realmente vocês são bons.

Acho que, pelo menos eu, vou parar por aqui. Estamos quase caindo na guerra santa da outra thread, hehehehe.

Att,
Vinicius Quaiato
www.viniciusquaiato.com

Twitter

2009/11/5 Alexandre Valente <alexandre...@gmail.com>

[Alexandre Valente]

Oi Vinicius,

Detectei um leve tom de ironia... :-). Mas muito longe disto. A equipe é senior, só isto. :-)

Eu sei que o que eu escrevi vai contra o que muitos "papas" falam. Mas eu realmente questiono muito TDD como algo que todos deveriam usar e como sendo algo que é benéfico sempre. Mas ok, continuo mantendo uma mente aberta e vou continuar fazendo análises sobre isto. Mas confesso que fiquei feliz de ver que não sou só eu que penso assim! :-)

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/6 Vinicius Quaiato <vinicius...@gmail.com>

[Carlos Garcia]

Minha opinião? Testes são caros... quem paga? O cliente! É um investimento que ele está disposto a fazer pela qualidade do produto que ele está comprando, se o cliente não quiser pagar os testes, eu não vendo o projeto. Mas TODOS os clientes ficam muito empolgados quando eu falo que o software dele pode ser testado de forma AUTOMATICA depois de qualquer alteração.

Apoio o TDD!

2009/11/6 Alexandre Valente <alexandre...@gmail.com>

--
[]s

Carlos Garcia

[Vinicius Quaiato]

Eu não entendo esse papo de "testes são caros", sinceramente.

A verdade é que o cliente JÁ ESTÁ PAGANDO por isso, no entanto nós não estamos fazendo isso.

O cliente já paga por um software testado, sem erros e que funcione como ele espera. Porém nós cobramos isso e não entregamos isso.

Att,

Vinicius Quaiato.

www.viniciusquaiato.com

2009/11/6 Carlos Garcia <carlosga...@gmail.com>

[Felipe Borges]

Eu acredito que TDD nao se resume somente a testes, ele influencia num entendimento maior dos requisitos e funcionalidades do sistema por parte dos desenvolvedores, vcs estao comentando sobre TDD como se fosse somente testes e mais testes, em um post do Giovanni Bassi (http://unplugged.giggio.net/unplugged/post/TDD-nao-existe.aspx) tem uma visao interessante sobre isso: "Um nome mais adequado seria Specification Driven Development, ou Specification Driven Design (SDD)."

Esta é minha opiniao.

[]'s

2009/11/6 Vinicius Quaiato <vinicius...@gmail.com>

--
PRABOR - Software Development - fel...@prabor.com.br
----------------------------------------------------------------
Felipe Prata L. Borges
MCT, MCPD .Net Framework 2.0: Web Applications
Contact: +55 19 9356 1355
msn: felip...@hotmail.com
skype: felipe.prabor

[Alexandre Valente]

Oi Felipe,

Não concordo muito não. Primeiro porque vc tem overhead de vc definir muito bem esta "especificação". E embora muitos falem que não, eu acho que fazer uma spec pra qqer coisa é um overkill. Imagina, vc vai fazer uma função trivial int Mult(int a,int b) { return a * b;}. Trivial certo? Escrevi "on the fly", em segundos. Se eu fosse fazer TDD disto iria primeiro escrever o teste... aí tentar imaginar como eu quero que isto funcione e como eu espero que isto quebre. O que acontece se eu passar ints de maneira que dê overflow? O que acontece se fo uma aplicação muti-thread? Como os erros devem ser retornados. Segundos vão virar vários e vários minutos.... Ou seja, TDD tem o potencial de tornar qqer coisa, por mais simples que seja, em um monstrinho! :-). E se vc for fazer o simples, que é testar se o resultado = a * b, isto seria completamente inútil (qual a chance do comp "errar" na conta? rsrs). Ou seja, pra coisas simples, ou complica sem necessidade ou é inutil., Pra coisas complexas, complica e muito... E pior, se vc vai fazer pra algumas coisas e pra outras não, qual o critério de decisão? No final, vc pode ter erros nesta fase tbm, e aí todo o seu esforço é questionávellll

Assim, vale a pena? Depende muito do sistema, do nivel que se quer de testes automatizados e etc... De repente, como o Carlos colocou, isto é uma ferramenta de marketing já que o cliente fica feliz de ver um monte de luzinhas verdes ao final de uma iteração..... Os meus com certeza não querem nem saber disto e querem é o software funcionando. :-)

E ainda no lance de especificação, usar testes para descrever é complicado... Sendo uma "linguagem de especificação", o desenvolvedor tem que ser treinado pra isto, pra pensar nos casos de erros, para não fazer só o lugar comum do caminho mais fácil etc... Possível? Claro, como falei conheço gente que faz isto muito bem. Mas para todos? Dificilmente. E eu sei que é muito caro treinar alguem pra trabalhar desta forma.

Portanto, sim, pra mim no final TDD is all about tests, ainda que vc chame isto de "especificação"  :-). E seu uso, como qqer metodologia ou ferramenta, deve ser avaliado caso a caso.

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/6 Felipe Borges <felip...@gmail.com>

[Vinicius Quaiato]

Felipe, também concordo contigo. No entanto existem muitas outras formas de garantir design e especificações, apesar do TDD ser a mão na roda no nível mais baixo.

No final das contas, o TDD te gerou um monte de testes que garantem as regras de negócio, independente de ele ter te ajudado no design ou não.

Att,

Vinicius Quaiato.

www.viniciusquaiato.com

2009/11/6 Felipe Borges <felip...@gmail.com>

[Vinicius Quaiato]

Alexandre, 

 

Não concordo muito não. Primeiro porque vc tem overhead de vc definir muito bem esta "especificação". E embora muitos falem que não, eu acho que fazer uma spec pra qqer coisa é um overkill. Imagina, vc vai fazer uma função trivial int Mult(int a,int b) { return a * b;}. Trivial certo? Escrevi "on the fly", em segundos. Se eu fosse fazer TDD disto iria primeiro escrever o teste... aí tentar imaginar como eu quero que isto funcione e como eu espero que isto quebre. O que acontece se eu passar ints de maneira que dê overflow? O que acontece se fo uma aplicação muti-thread? Como os erros devem ser retornados. Segundos vão virar vários e vários minutos.... Ou seja, TDD tem o potencial de tornar qqer coisa, por mais simples que seja, em um monstrinho! :-). E se vc for fazer o simples, que é testar se o resultado = a * b, isto seria completamente inútil (qual a chance do comp "errar" na conta? rsrs). Ou seja, pra coisas simples, ou complica sem necessidade ou é inutil., Pra coisas complexas, complica e muito... E pior, se vc vai fazer pra algumas coisas e pra outras não, qual o critério de decisão? No final, vc pode ter erros nesta fase tbm, e aí todo o seu esforço é questionávellll

 

Eu até concordo com você, mas você tem que concordar que da forma como você fez possivelmente existem bugs na aplicação de regras de negócio.

Agora vamos pra um caso mais realista, onde essa multiplicação/cálculo envolva regras de negócio (primeiro valor deve ser positivo, se o segundo valor for maior que o dobro do primeiro não multiplique, se o segundo valor for negativo aplique uma outra fórmula, etc, etc, qlqr regra inventada), o TDD faria você realmente pensar e garantir estas especificações. E o melhor, a cada implementação de novas regras (afinal sempre começamos e vamos evoluindo o código) você tem certeza de que tudo está lá e funcionando!

Sem especificar você não entrega nada ao cliente, ao menos nada do que ele espera.

Att,

Vinicius Quaiato.

www.viniciusquaiato.com

[Emmanuel G. Brandão]

Alexandre,

 

Quando você disse que a sua equipe sênior já tem muita prática e eles sabem o que terá problema ou não, eles mentalmente não estão fazendo testes? Pois é, será que quando eles inserem um código novo eles mentalmente testam todo o software? Não, é impossível concorda?

Tá então, alguma coisa seria interessante ser testada, alguma regra de negócio, alguma funcionalidade, e para isso que serve a cobertura de testes. Você vai definir até que ponto quer testar.

O seu exemplo é algo que eu provavelmente não testaria... Ou testaria já que você questionou dar um overflow no int. Tudo depende. Agora, esse seu exemplo é simplório demais, porém, você garante que o usuário não vai colocar um inteiro gigante pra dar esse overflow? Como? O desenvolvedor sempre verifica todas as possibilidades?

Ao longo do dia quantas vezes o desenvolvedor irá rodar um debugg? E se quando ele arrumar um problema conflitar em outro lugar?

A conclusão que eu cheguei quanto a testes é: se eu vou testar uma única vez o software o teste é caríssimo! Mas qual software é testado apenas uma vez?

Brandão, Emmanuel G.
CSM
blog.egomesbrandao.net

___________________________________
Ao encaminhar esta mensagem, por favor:
1 - Apague meu endereço eletrônico;
2 - Apague também os endereços dos amigos que receberam juntamente com você a mensagem, antes de enviar;
3 - Encaminhe como Cópia Oculta (Cco ou BCc) aos seus destinatários. Dificulte assim a disseminação de vírus, spams e banners.

[Alexandre Valente]

Oi Emmanuel,

Exatamente! Se o desenvolvedor é senior o suficiente pra ter estas dúvidas e saber se é necessário ou não testar, ele provavelmente já está fazendo o código correto pro cenário dele. E aí então pra que perder tempo com testes? Se o cara não consegue nem ter estas dúvidas, ele provavelmente não vai conseguir escrever o teste correto, então, de novo, pra que testes? rsrs.

Por testes eu me refiro a testes escritos (unit tests)... Claro que fazemos isto mentalmente. Sei que estou jogando pros extremos, mas minha idéia e fazer uma oposição a uma crença crescente de que TDD é a a única e melhor maneira de programar... Discordo, acho que depende... :-).

Abs

Alexandre

2009/11/6 Emmanuel G. Brandão <egomes...@gmail.com>

[Emmanuel G. Brandão]

OK... Então já que você concorda que um programador testa mentalmente, como fazer testes integrados mentalmente? :)

Não rola, certo? Então um módulo muito testado integrado com um outro módulo muito testado não é garantido que funcionem corretamente certo?

[Alexandre Valente]

Então. Mas aí vem, é necessário se ter testes integrados pra todos os sistemas? Se já estávamos falando de custos aliados a TDD, temos aí agora toda uma nova gama de custos. Montar um ambiente de integração contínua (que não é trivial) e manter este ambiente é caro no mínimo pelo nível dos profissionais que são capazes de fazer isto. 

E quando o projeto tem partes "legadas" complica ainda mais para montar um ambiente assim. Eu já participei da montagem de dois, nos dois casos eu não achei que valeu o custo/benefício, se eu estivesse no lugar do cliente. Mas é claro que existem outros fatores (nestes casos, o marketing foi muito importante, daí se justificou). 

Perceba o meu ponto, tenho certeza que existem muitos cenários em que um ambiente de integração contínua faça todo o sentido. Mas também tem muitos, talvez maioria, que não faça. Hoje, com toda a minha infraestrutura já montada, eu ainda tenho um custo de setup de inicial, mesmo para pequenos projetos, que não é pequeno. Se eu fosse incluir nisto um setup de integração contínua, a coisa iria aumentar significativamente E para um projeto pequeno dar lucro, é necessário ficar de olho em todos estes custos. 

Acho que no final das contas, como mencionei, todas as metodologias e ferramentas devem ser usadas para resolver um problema e não porque elas são "legais". Se seu ambiente tem equipe numerosa, deploys grandes e frequentes e o seu sistema seja extremamente crítico, talvez TDD + Integração contínua seja ideal. No meu caso, equipe mínima, só seniores, projetos em sua maioria antigos (alguns com 10 anos), entregas pequenas mensais (quinzenais no pior caso), e nada crítico o suficiente que não possa mesmo ficar parado por algumas poucas horas (e nem me lembro quando isto aconteceu da ultima vez!), para empresas médias que estão extremamente preocupadas com ROI, com certeza não se justifica.

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/6 Emmanuel G. Brandão <egomes...@gmail.com>

[Juan Pedro A. Lopes]

Sem testes unitários e sem integração contínua? Sem comentários.

Brincadeira :P Só falei isso pq achei que ficaria sonoro. Mas sei lá, realmente me assusta um ambiente assim.

2009/11/6 Alexandre Valente <alexandre...@gmail.com>

[Vinicius Quaiato]

Alexandre,

Então. Mas aí vem, é necessário se ter testes integrados pra todos os sistemas? Se já estávamos falando de custos aliados a TDD, temos aí agora toda uma nova gama de custos. Montar um ambiente de integração contínua (que não é trivial) e manter este ambiente é caro no mínimo pelo nível dos profissionais que são capazes de fazer isto. 

Esse argumento pra mim ainda é inválido. Como disse várias vezes antes, o custo dos testes está já embutido em todos os projetos... A questão é você escolher uma metodologia, e o TDD não é uma que irá fazer o custo aumentar.

 

E quando o projeto tem partes "legadas" complica ainda mais para montar um ambiente assim. Eu já participei da montagem de dois, nos dois casos eu não achei que valeu o custo/benefício, se eu estivesse no lugar do cliente. Mas é claro que existem outros fatores (nestes casos, o marketing foi muito importante, daí se justificou). 

Aqui na empresa somos em 15 devs. Temos um VSTS configurado e pronto. Nunca mais precisamos configurar nada. Entra projeto novo, é só criar no VSTS, configurar build, e já era. Não vejo como cada projeto tendo um custo de setup.

 

Acho que no final das contas, como mencionei, todas as metodologias e ferramentas devem ser usadas para resolver um problema e não porque elas são "legais". Se seu ambiente tem equipe numerosa, deploys grandes e frequentes e o seu sistema seja extremamente crítico, talvez TDD + Integração contínua seja ideal. No meu caso, equipe mínima, só seniores, projetos em sua maioria antigos (alguns com 10 anos), entregas pequenas mensais (quinzenais no pior caso), e nada crítico o suficiente que não possa mesmo ficar parado por algumas poucas horas (e nem me lembro quando isto aconteceu da ultima vez!), para empresas médias que estão extremamente preocupadas com ROI, com certeza não se justifica.

Também não entendo como o TDD não está aliado ao ROI, uma vez que ele visa extaamente garantir aquilo que dará o retorno, ou seja, garantir aquilo que o cliente pediu e precisa que seja feito e que funcione.

 Bom como eu havia dito (e não consegui cumprir) vou parar de comentar essa thread. Estamos toda hora falando as mesmas coisas :p

Só eu percebi isso?!

Att,

Vinicius Quaiato.

www.viniciusquaiato.com

[Leo D]

>
> Acho que no final das contas, como mencionei, todas as metodologias e
> ferramentas devem ser usadas para resolver um problema e não porque
> elas são "legais". Se seu ambiente tem equipe numerosa, deploys
> grandes e frequentes e o seu sistema seja extremamente crítico, talvez
> TDD + Integração contínua seja ideal. No meu caso, equipe mínima, só
> seniores, projetos em sua maioria antigos (alguns com 10 anos),
> entregas pequenas mensais (quinzenais no pior caso), e nada crítico o
> suficiente que não possa mesmo ficar parado por algumas poucas horas
> (e nem me lembro quando isto aconteceu da ultima vez!), para empresas
> médias que estão extremamente preocupadas com ROI, com certeza não se
> justifica.
>

O pragmatismo que falta às vezes nos desenvolvedores acaba se
desenvolvendo quando a pessoa passar a ser responsável (ou lida de
perto) com as necessidades comerciais de um projeto. Fazer um projeto
dar lucro, cuidar com o custo/benefício de cada decisão, não fazer de
mais, nem de menos na arquitetura, enfim... eu acho que esse equilíbrio
vem mais rápido para quem tem um olhar (também) comercial. Quem está
trabalhando com tecnologia e se preocupa apenas com a tecnologia, a sopa
de letrinhas sempre vai ser justificável e atraente.

[]s

[Giovanni Bassi]

Eu também achoq ue TDD não é a unica arma para chegar a um bom design.
Mas sem dúvida, é a melhor.

Digo com experiência de causa. Eu já fazia bons designs antes de trabalhar com TDD. Agora eu faço designs melhores.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/5 Rafael Noronha <rafan...@gmail.com>

Eu acho bastante sensato o posicionamento do autor.

É o que eu venho defendendo ultimamente: avalie o custo de tudo.

Testar é custoso, ponto.

Não testar será ainda mais custoso?
A resposta errada é sim.
A resposta certa é talvez.

Escrever uma porrada de testes unitários - mesmo tendo uma boa noção
do que você está fazendo, pode sim ser pior do que não escrever nenhum
deles.

Escreva um código limpo, expressivo e apoiado em boas técnicas.
Especifique e garanta o funcionamento de negócio com testes de
aceitação e integração.

TDD não é a única arma para se chegar a um bom design, documentar o
código ou prevenir bugs.

E nem sempre deixar de testar é faltar com profissionalismo.

Isso não passa de uma excelente jogada de marketing do Uncle Bob.

[Giovanni Bassi]

Hoje estava examinando algumas arquiteturas para interface gráfica no cliente. O projeto era WPF, e depois de analisarmos as arquiteturas mais comuns (passive view, supervising controller, PM, etc), chegamos no MVVM. Fizemos um protótipo, tudo funcionou bem, o cliente gostou. O projeto está no segundo mês, mas já está na segunda sprint, e já tem bastante código entregue, inclusive de interface gráfica. Esse código vai ter que ser refeito, porque está com diversos problemas. Vamos reaproveitar a maioria do XAML, mas o código C# vai ser quase todo refeito.
Fomos reescrever uma tela . Como? Com TDD, claro.
O cliente tinha uma visão de que o MVVM trazia um grande valor, mas talvez fosse muito complicado em alguns cenários. Começamos devagar, baby steps, um teste de cada vez. Em pouco tempo os primeiros view models apareceram, e se integraram perfeitamente no modelo, baseado em WCF na frente de uma arquitetura baseada em DDD e Domain Events. Algumas operações, que pareciam super complexas, foram sendo entregues. Terminei o trabalho hoje por lá deixando pra eles progredir nos testes, e implementar as views com base nas views que já existiam.

Podia fazer sem TDD? Claro! Mas com TDD o resultado foi nitidamente rápido.
Observação: na equipe há juniors, plenos e sêniors.

Alexandre, com todo o respeito, não consigo entender como desenvolver com testes antes pode te deixar improdutivo. Só consigo vislumbrar TDD atrapalhando se as suas escolhas arquiteturais estão sendo feitas de maneira pouco adequada. Se estivessemos usando um page controller, por exemplo, seria muito mais difícil seguir com testes para o comportamento da interface gráfica.
Sabendo também que você advoga um modelo anêmico, será que TDD não é o típico de prática que, quando somadas a outras, tem na sua soma algo maior do que as partes? Em outras palavras: será que a falta de um modelo rico, ou de outro tipo de princípio, não está impedindo você de ser eficiente com TDD?

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/5 Alexandre Valente <alexandre...@gmail.com>

Oi,

Sou mais um do "contra". No meu caso especificamente, eu concordo completamente com o autor. Testar (bem) é caro, e com certeza diminuiu minha produtividade. (Já imagino a facção fundamentalista TDD preparando para o fuzilamento! rsrs). E sim, conheço TDD, já vi pessoas que fazem isto muito bem trabalhando e eu mesmo já usei, da maneira prevista, em vários cenários para avaliar. E minha conclusão é a mesma do autor, em vários cenários isto pode se mostrar inviavelmente caro.

Significa que TDD é ruim? Óbvio que não, estou falando do meu caso em específico.... Claro que em equipes onde várias pessoas, de níveis diferentes mexem no código e em uma diversidade de outros cenários, com cerrteza TDD é muito útil. Mas eu vou contra a opinião de vários xiitas de que TDD "is the only true way"... :-). Acredito que em times pequenos, só de seniores, a utilização de TDD vai aumentar custo sem contrapartida. E aí o seu uso tem que ser ponderado, pode ser que valha a pena, pode ser que não valha... Nos meus projetos atuais, com certeza não vale.

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/5 Vinicius Quaiato <vinicius...@gmail.com>

@Rafael

Eu acho bastante sensato o posicionamento do autor.

Por que?

 

Não testar será ainda mais custoso?
A resposta errada é sim.
A resposta certa é talvez.

Eu diria que a resposta é: Não ter testes que garantam aquilo é perigoso, não te dá garantias de futuras modificações! Logo, você perderá mais tempo em "testes do macaco".

 

Escrever uma porrada de testes unitários - mesmo tendo uma boa noção

do que você está fazendo, pode sim ser pior do que não escrever nenhum
deles.

Por que podem ser pior? 

 

Escreva um código limpo, expressivo e apoiado em boas técnicas.

Especifique e garanta o funcionamento de negócio com testes de
aceitação e integração.

Existem bugs que não são vistos a olho nu...

 

TDD não é a única arma para se chegar a um bom design, documentar o
código ou prevenir bugs.

Eu considero que os testes que ali estão garantem a não criação de bugs no futuro. Mantenha-os verde e tudo está ok. Evolua o código, evolua os testes e tudo está ok. Altere um classe, mantenha os testes verdes e tudo está ok.

 

E nem sempre deixar de testar é faltar com profissionalismo.

Não?!

Att,

Vinicius Quaiato.

www.viniciusquaiato.com

[Giovanni Bassi]

Acredito que seja possível alcançar o mesmo objetivo sem testar todo o sistema unitariamente.

>> > E nem sempre deixar de testar é faltar com profissionalismo.
> >
> >Não?!

Definitivamente não.

Discordo. Desenvolvedor que não testa não é profissional.

[Giovanni Bassi]

Rafael,

Se o meu código é bem estruturado, eu não preciso testar cada
pedacinho dele, já que a responsabilidade de cada pedacinho é
evidente.

Não acho que a responsabilidade de cada pedacinho do código é evidente. Aí está o problema.
Além disso, você não escreve testes para testar código que te parece evidente hoje. Você escreve para testar ele daqui um mês, e garantir que aquele pedacinho ainda funciona.
E escreve antes, para garantir que vai especificar direito.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/5 Rafael Noronha <rafan...@gmail.com>

Juan,

> > Escreva um código limpo, expressivo e apoiado em boas técnicas.
> > Especifique e garanta o funcionamento de negócio com testes de
> > aceitação e integração.
>

> Escreva um teste limpo, expressivo e apoiado em boas técnicas e você vai
> perceber que escrever um código desse jeito nem é tão importante. O simples
> fato de criar testes unitários facilitará seu caminho em tornar aquele
> código independente o suficiente para ser mudado assim que preciso.
>
> Sério, imagine um processo muito grande. Imagine esse processo todo descrito
> num único método sem comentários (mas que funciona). Você, bom programador,
> pensa "Putz, isso está errado. Deixe-me quebrar esse método em métodos
> menores". Nesse ponto, você assume a responsabilidade de fazer o método
> continuar funcionando, e é uma senhora responsabilidade.
>

Se o meu código é bem estruturado, eu não preciso testar cada
pedacinho dele, já que a responsabilidade de cada pedacinho é
evidente. Testes de integração serão o suficiente, já que testar o
micro não gera valor significativo.

> Agora, imagine que existem dezenas de métodos que especificam os caminhos
> mais críticos desse processo. Esses são os testes unitários, exercendo sua
> segunda melhor função: documentar. Nesse ponto, você passa a entender o que
> o processo deveria fazer, e sente-se muito mais confiante para mudar o
> código para melhor, apertar o "Run" e ver que os testes continuam passando.
> Sem melhor design, sem comentários inline. Não que coesão não seja
> importante, mas toda a coesão realmente necessária pode ser aquela obtida
> pelo que os testes unitários lhe obriga.

Me parece que a documentação que você gera através de seus testes
unitários, eu gero diretamente no meu código em produção, com o
capricho que ao seu ver não é tão importante.

Além disto os testes de integração são a forma mais perfeita de
documentação.
Já viu o que é possível fazer com o Fitnesse?

[Giovanni Bassi]

O tempo que você perde debugando manualmente para ver o que está errado é muito maior do que o tempo que você perderia escrevendo um teste.
Se isso não é verdade, há problemas de acoplamento muito alto no seu código.
Aí você tem que resolver esse outro problema antes.
Quem sabe se você escrever o teste antes... TDD ajuda a desacoplar o código!  ;)

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/5 Alexandre Valente <alexandre...@gmail.com>

[Giovanni Bassi]

Testar é caro.

Não testar é mais caro ainda.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/6 Carlos Garcia <carlosga...@gmail.com>

[Giovanni Bassi]

Alexandre,

TDD é sobre testes, mas é muito mais sobre especificação. Se você não entender TDD desta forma, você não entendeu o TDD.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

[Alexandre Valente]

Oi Giovanni,

Rsrsrs... Tbm, com todo respeito, não sei com que tipo de time vc trabalha mas com certeza deve ser pessoas de nivel muito superior às que eu conheço. Como falei, eu entendo TDD, conheço gente que faz isto muito bem. Mas a maior parte das pessoas que eu conheço, a maioria delas seniores, NÃO sabe fazer TDD. E se vc acha que treinar gente pra fazer é barato, eu gostaria muito que vc me enviasse alguns currículos! (se vc falar que é fácil treinar qualquer um pra usar sempre TDD, então estamos em planetas diferentes :-)... eu já passei por várias expericiencias e não, treinar alguém pra fazer TDD corretamente não é nada simples!) E pode ser que meu comercial tbm não seja tão bom, mas eu não consigo repassar custos de treinamento ou de "tecnlogia" sem ROI claro para os meus clientes, eles conhecem o suficiente pra questionar bem os custos que eles tem.... E a venda de aumento de qualidade por TDD não cola, já que não tem nada de errado com a qualidade atual do que eles compram.... :-)

Acho que vc já deve ter me conhecido pelo posts. Modelo rico ou anemico, TDD ou não TDD, Integração Contínua ou não, pra mim são decisões que estão sempre subordinadas a duas coisas: 1) Tenho que entregar software que deixe meus clientes satisfeitos. 2) Tenho que ter lucro caso contrário a minha empresa quebra e e não consigo mais fazer o 1!!! :-) Assim, eu não sou "contra" nada disto, eu simplesmente estou buscando maneiras de fazer isto de forma eficiente que me gere resultado no final. Pode ser que, como falei, o pessoal que eu encontrei até hoje não seja bom o suficiente pra fazer isto de forma eficiente (e eu estou nesta lista). Mas a minha opinião é que todas estas práticas ainda não são mainstream para ser commodity, elas tem aplicações em projetos específicos e fazer isto indiscriminadamente pode tornar facilmente um projeto inviável. 

Claro que estou sempre buscando novas maneiras de aplicar bons conceitos e tecnlogias P. ex., o Phillip me colocou algumas idéias sobre modelos ricos que eu já estou preparando pra adaptar, pode ser que eu consiga encaixar.... Mas usar TDD sempre eu ainda acho bem dificil.

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/6 Giovanni Bassi <gig...@gmail.com>

[Rafael Noronha]

Giovanni,

>> Se o meu código é bem estruturado, eu não preciso testar cada
> > pedacinho dele, já que a responsabilidade de cada pedacinho é
> > evidente.
>
>
> Não acho que a responsabilidade de cada pedacinho do código é evidente. Aí
> está o problema.
> Além disso, você não escreve testes para testar código que te parece
> evidente hoje. Você escreve para testar ele daqui um mês, e garantir que
> aquele pedacinho ainda funciona.
> E escreve antes, para garantir que vai especificar direito.

Não vejo problemas no seu raciocínio, só questiono a aplicabilidade de
testes unitários no dia-a-dia.

Existem situações onde não vale a pena utilizar determinada prática,
dada alguma limitação de projeto.

Se você não abre mão de escrever testes ou qualquer outra prática
eficiente (porém custosa) em um projeto com este tipo de limitação (a
grande maioria dos projetos por aí), então quem não é profissional é
você, por colocar a entrega do projeto em segundo plano.

Meu problema nem é com a efetividade dos testes unitários, e sim com a
proposta de um dogma onde a escrita de testes unitários ou a prática
de tdd são indispensáveis para o sucesso de um projeto ou para a
qualidade profissional de um desenvolvedor.

[Juliano Oliveira]

Giovanni,

Pega leve!

Desenvolver testes de software é mais complicado que desenvolver software. 

Eu não faço muitos testes por não saber muito bem se meus testes são efetivos, por isso acabo deixando um pouco de lado. Só se consegue testar e testar bem com a experiência.

Concordo que TDD deve ser fundamental, mas não que um dev que não esteja habituado a testar não seja profissional.

[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
twitter: @juloliveira - skype: juloliveira
http://programandoem.net
http://www.plug7.com.br

2009/11/6 Giovanni Bassi <gig...@gmail.com>

[Giovanni Bassi]

Juliano, se o desenvolvedor não testa, então ele não sabe se o código dele funciona. Ele sabe que, quando depurou, ou acessou alguma tela, o resultado que ele recebeu foi o esperado, naquele momento. E daqui um mês, será que ainda funciona?
Eu acredito que há um problema de cultura na industria. Sem testes não há garantia de funcionamento. E não estou falando só testes unitários, mas testes de aceitação, testes integrados, etc, etc... É responsabilidade do desenvolvedor desenvolver os testes mais adequados ao código que ele está escrevendo.

Sei que muitos não estão treinados e preparados para escrever testes. Mas isso é outro problema, que temos que resolver. É como um médico dizer que saber operar o coração, mas não sabe fechar o paciente depois. Ainda que o resultado esteja entregue, está faltando alguma coisa.
Acho que os profissionais devem desenvolver esta competência o quanto antes. Ela é muito importante. Já falamos de senioridade no grupo antes, e pra mim senioridade é algo que passa por diversas coisas, entre elas, o desenvolvedor pode ser sênior para lidar com ASP.Net, mas não para trabalhar com Silverlight, por exemplo. Mas se ele não sabe testar, não é sênior em nada. Veja que essa é minha concepção pessoal de senioridade, que, pelo visto, não vai ser aceita por boa parte do grupo. Ainda assim, temos um problema histórico de qualidade no mercado. Será que não há ligação entre essa cultura de que não testar é ok, e esses problemas de qualidade?

Sei que dizendo isso estou pisando no calo de muita gente dizendo esse tipo de coisa, mas espero que entendam isso como uma recomendação. Além disso, a visão de que teste é fundamental está crescendo e começando a ser demandada cada vez mais no mercado.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/7 Juliano Oliveira <jul.ol...@gmail.com>

[Juan Pedro A. Lopes]

Sem contar que é muito mais motivante programar com testes.

Só quem realmente tentou sabe disso.

2009/11/7 Giovanni Bassi <gig...@gmail.com>

[Leo D]

"Mas se ele não sabe testar, não é sênior em nada. "

Giovanni, a diferença é que você tem pra você que [testar == testes de
unidade], enquanto outros do grupo usam os testes de unidade em menor
porção e cobrem o restante dos testes de outra maneira - seja depurando
com breakpoints, ou com testes de integração, testes de "caixa preta",
testes de aceitação pelo cliente que comprou o software, testes com
gravação de macros usando Watin, Selenium, Fitnesse... Isso vai da
cultura da empresa e do desenvolvedor. Eu já trabalhei em empresa grande
que tinha "departamento de testes", onde contratavam pessoas para seguir
um script, executando ações no programa e observando seu comportamento,
observando o estado do banco, etc. Essa é melhor forma de testar?
Provavelemente não. Mas funcionava? Sim, funcionava.

No desenvolvimento de software é muito comum você ter várias formas de
fazer um trabalho (seja em código ou metodologia), bifurcações onde
decidimos com o critério do gosto e da cultura (e não do certo ou
errado), então acho que rotular de profissional / não profissional
apenas porque é diferente da forma que você mesmo pratica, aí já vira
religião. E de religião tecnológica já basta o R. Stallman e FOSS :-)

[]s

[Pedro Reys]

Acredito que a grande confusão é que alguns, normalmente os que defendem a opcionalidade - entendem TDD como algo relacionado a testes - enquanto outros - normalmente os que defendem seu uso sempre - entendem TDD como uma ferramenta de Design.

TDD tem muito mais haver com o processo de Design do que com os Testes propriamente ditos.


- Pedro Reys

2009/11/7 Leo D <l...@codigofluente.com.br>

[Juliano Oliveira]

Pisar no calo seria dizer algo como "Quem não testa está desatualizado" ou "Quem não testa está trabalhando errado".

Dizer que quem não testa "não é profissional" é pisar um pouco mais acima, nas bolas no caso, ou seja, é mais pessoal.

[]´s

Juliano Oliveira
Analista Desenvolvedor
.Net, C#, Actionscript, Flex, NHibernate
twitter: @juloliveira - skype: juloliveira
http://programandoem.net
http://www.plug7.com.br

2009/11/7 Giovanni Bassi <gig...@gmail.com>

[Vinicius Quaiato]

Eu só dou graças à Deus por nós não desenvolvermos remédios, ahahhaha!

Imagina?!

"Vamos colocar esse remédio em produção e então vamos debugar depois..."

Ufa! Ainda bem que somos geeks e lidamos com código.

Att,
Vinicius Quaiato
www.viniciusquaiato.com

vinicius.quaiato

Twitter

2009/11/7 Juliano Oliveira <jul.ol...@gmail.com>

[Giovanni Bassi]

Oi Leo,

Eu não disse que testar é igual a teste unitário. Pelo contrário, escrevi que cabe ao desenvolvedor utilizar os testes mais adequados. Concordo que trabalhar com testes de aceitação é fundamental. Mas igualmente fundamental é trabalhar com testes unitários.

E quanto ao "não é o melhor mas funcionava", quando os médicos não lavavam as mãos para operar muitas pessoas morriam. Mas muitas não morriam. Não é o melhor, mas funcionava. Como o Vinicius disse, ainda bem que não fazemos remédio. Será que podemos dizer que as pessoas que desenvolvem remédios são mais profissionais que as pessoas que desenvolvem software?

Eu acho que o grande problema é que quando você entrega algo quebrado, você está quebrando também a sua palavra. Você disse que funcionava e não funciona. É nossa obrigação entregar o que dissemos que iríamos entregar.

Concordo que há sempre várias formas de fazer um trabalho. É possível fazer o desenvolvimento sem testes unitários ou de aceitação, e fazer só testes de caixa preta? Claro! É a melhor maneira? Não, é a maneira mais cara, e a mais propensa a bugs e retrabalho.
Eu trabalho sempre focado na melhor maneira. Minha consultoria é focada nisso: fazer direito, fazer de forma sustentável e mais barata possível, e fazer flexível, já que, se errarmos, podemos mudar rapidamente. E só testes dão essa garantia (apesar do que o cara lá do artigo que deu origem a essa thread disse, inocentemente).

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/7 Leo D <l...@codigofluente.com.br>

[Giovanni Bassi]

Juliano,

Pegando o exemplo do Vinicius, você acharia profissional um farmacêutico que te entregasse, numa farmácia de manipulação, um remédio que não possuia as especificações receitadas pelo seu médico?
E porque é profissional um desenvolvedor que cria um software que não funciona?

E como você garante que um software funciona? Você testa. É a única maneira. Debugar garante que o software funcionou aquela uma vez que você rodou. E as características sistêmicas tendem ao caos, é natural que o software tenda ao caos.
(Agora vou parar, estava tendo pensamentos Akitanos, ia falar de entropia e tudo mais, mas deixa pra lá)

[Alexandre Valente]

Oi Giovanni,

Nossa, esta thread já rendeu. Mas realmente vejo uma diferença conceitual grande, talvez por falha de comunicação? Vou marcar de ir a SP e a gente continua regado a chopp, de repente converge mais rápido! :-)

Toda a questão é que vc assume que que faz teste unitário faz melhor software. É igual falar que só scrum gera software bom. Ou só quem programa .NET faz software bom. Isto não é verdade. Quem é bom, é bom em qualquer linguagem, qualquer ferramenta (claro que ele vai ser infinitamente mais produtivo em determinado ambiente/metodologia do que em outra). Assim, quem faz bom software, o faz com ou sem TDD. Tem gente que pode ser mais produtivo com TDD (parece ser o seu caso). Tem gente que não é (o meu), e sim, definitivamente já tentei e usei (mesmo) e até gostei pra alguns cenários.

O problema é que fazer testes não é garantia de nada. Se o cara não fizer o teste correto, não aplicar a prática correta, não conseguir entender o que ele está fazendo nem as condições de contorno, ele vai fazer péssimos testes. É como o médico que não sabe operar falar "hmm. se eu lavar as mãos, vai dar tudo certo". E o paciente morre de todo jeito. (esta é uma razão de eu achar péssima esta analogia, fazer alguns testes unitários NÃO é garantia de que vc está fazendo a coisa certa). Pra fazer TDD bem feito, vc tem que tratar todos estes itens, ou seja, vc tem que ser bom! 

Agora se o cara é bom e vai fazer bom software de um jeito ou de outro, eu acho que o uso de TDD deve ser considerado como qqer outra metodologia/ferramenta. Ora, se eu tivesse uma equipe de 5 Giovannis :-) :-), eu provavelmente iria usar TDD em todos os meus projetos, afinal o time seria muito mais produtivo assim! Agora o que eu vejo é que o pessoal não sabe fazer isto naturalmente. E treinar não é nada simples. Assim, nem sempre é possível ou recomendado fazer, tem que ver caso a caso.

Bom, espero que eu tenha conseguido me fazer entender um pouco mais. Senão, vamos marcar o chopp!! :-)

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/8 Giovanni Bassi <gig...@giggio.net>

[Juan Pedro A. Lopes]

Passagens pra São Paulo estão menos de 100 reais ida e volta. Quem sabe não rola de ir um final de semana ai. Gostei da idéia.

2009/11/8 Alexandre Valente <alexandre...@gmail.com>

[Rafael Noronha]

Segue um texto bastante pertinente, escrito pelo Steve Sanderson.

Interessante o gráfico que ele fez, traçando o custo benefício em
testar unitariamente diferentes tipos de código.
O raciocínio dele está bastante alinhado ao meu, no sentido de não
buscar 100% de cobertura de testes unitários, e não superestimar o
valor deste tipo de teste.

http://blog.codeville.net/2009/11/04/selective-unit-testing-costs-and-benefits/

[Juan Pedro A. Lopes]

The tendency – either by you or your colleagues – to avoid improving and refactoring application code out of fear that it may break a load of unit tests and hence incur extra work

Eu acho que justamente o contrário acontece. Eu tenho medo de refatorar um código para o qual não existe teste unitário. Por mais óbvio que pareça o método.

Por diversas vezes, quando precisei refatorar códigos de terceiros que não tinham testes unitários, primeiro escrevi testes para garantir o comportamento que ele conhecidamente tinha, depois refatorei seguindo esses testes.

2009/11/8 Rafael Noronha <rafan...@gmail.com>

[Giovanni Bassi]

Oi Alexandre,

É isso aí, venha a SP num sábado de reunião do DNA, e já esticamos depois! :) Ou outro dia qualquer.

É claro que você pode fazer código com bugs e com testes. É só testar as coisas erradas, escrever testes que não testam nada. Aí é como o médico que lava a mão muito mal. Além disso, há outras técnicas envolvidas, é como você disse, o médico lava a mão e o paciente morre, porque ele não sabia operar. Da mesma forma, você pode fazer os testes e fazer um software que não faz o que o cliente espera, ou com uma arquitetura muito difícil de evoluir.
Mas sem os testes as chances de bugs são ainda maiores, como são maiores as chances de um paciente morrer se o médico não lavar as mãos.

Testes não são a garantia. São o caminho para ela.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/8 Alexandre Valente <alexandre...@gmail.com>

[Giovanni Bassi]

+1

Concordo totalmente. Sem uma especificação que garanta o funcionamento do médico, ou você refatora com medo e muito mais devagar, ou você refatora rezando pra dar certo.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/8 Juan Pedro A. Lopes <zero...@gmail.com>

[Juan Pedro A. Lopes]

Oportunidade de negócio: lançar um saponáceo com o nome "NUnit - versão mesa de operação". :)

just kidding

2009/11/8 Giovanni Bassi <gig...@gmail.com>

[Rafael Noronha]

Este argumento também achei inválido, mas não desmerece outros pontos
importantes levantados no texto.

[Pedro Reys]

Aproveitando a discussao, alguem já leu esse livro: http://www.amazon.com/Growing-Object-Oriented-Software-Guided-Tests/dp/0321503627

Recomenda?

- Pedro Reys

2009/11/8 Rafael Noronha <rafan...@gmail.com>

[Vinicius Quaiato]

Só pra aproveitar, quando é a próxima reunião!?

Att,
Vinicius Quaiato
www.viniciusquaiato.com

vinicius.quaiato

Twitter

2009/11/8 Giovanni Bassi <gig...@gmail.com>

[Alberto Chvaicer]

Voltando aos testes.
Alguém já usou o Spec Explorer? ( http://msdn.microsoft.com/en-us/devlabs/ee692301.aspx )

2009/11/8 Vinicius Quaiato <vinicius...@gmail.com>

[Giovanni Bassi]

Wow... Scary...

Sendo uma pessoa que escreve testes antes, eu não sei se gosto... Assisti o video. É interessante, mas é o oposto de TDD. Dessa forma, a especificação é escrita pra você, com base no modelo... a cultura de usar os testes para regressão vai por água abaixo... O que vocês acham?

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/9 Alberto Chvaicer <achv...@gmail.com>

[Vinicius Quaiato]

Naõ sei bem como isso "vive junto com TDD", mas o esquema de gerar os testes é até que interessante para uma cobertura de 100% hein?!

É preciso ver mais sobre pra entender bem.

Att,
Vinicius Quaiato
www.viniciusquaiato.com

vinicius.quaiato

Twitter

2009/11/10 Giovanni Bassi <gig...@gmail.com>

[Ivan Sanchez]

Alexandre,

Como você está quantificando este custo de "quebra"? Debugar algo
que já foi entregue não custa só tempo de desenvolvimento. E dentre
estes custos o mais crítico é o tempo do usuário, que quando
negligenciado pode acabar com um projeto.

--
Ivan Sanchez
http://www.isanchez.net

On Nov 6, 12:15 am, Alexandre Valente <alexandre.g.vale...@gmail.com>
wrote:

> abs
>
> Alexandre Valente
> MCSE+I, MCSD, MDCBA, ITIL, CSM
> agvalente.wordpress.com
>

> 2009/11/5 Vinicius Quaiato <vinicius.quai...@gmail.com>

>
> > @Alexandre,
> > Por que você diz que testar é caro, ou praticar TDD é caro? Não entendo
> > como isso pode ser mais caro.
> > Na minha singela utilização de TDD tenho percebido que é mais rápido,
> > prático, e garante muito mais do que simplesmente o teste do macaco.
>
> > Para mim caro é perder tempo, e não vejo perda de tempo com TDD.
> > Além do TDD ser rápido e prático, os testes permanecem lá, ao contrário dos
> > testes do macaco.
>
> > Att,
> > Vinicius Quaiato.
> >www.viniciusquaiato.com
>

> > 2009/11/5 Alexandre Valente <alexandre.g.vale...@gmail.com>

>
> > Oi,
>
> >> Sou mais um do "contra". No meu caso especificamente, eu concordo
> >> completamente com o autor. Testar (bem) é caro, e com certeza diminuiu minha
> >> produtividade. (Já imagino a facção fundamentalista TDD preparando para o
> >> fuzilamento! rsrs). E sim, conheço TDD, já vi pessoas que fazem isto muito
> >> bem trabalhando e eu mesmo já usei, da maneira prevista, em vários cenários
> >> para avaliar. E minha conclusão é a mesma do autor, em vários cenários isto
> >> pode se mostrar inviavelmente caro.
>
> >> Significa que TDD é ruim? Óbvio que não, estou falando do meu caso em
> >> específico.... Claro que em equipes onde várias pessoas, de níveis
> >> diferentes mexem no código e em uma diversidade de outros cenários, com
> >> cerrteza TDD é muito útil. Mas eu vou contra a opinião de vários xiitas de
> >> que TDD "is the only true way"... :-). Acredito que em times pequenos, só de
> >> seniores, a utilização de TDD vai aumentar custo sem contrapartida. E aí o
> >> seu uso tem que ser ponderado, pode ser que valha a pena, pode ser que não
> >> valha... Nos meus projetos atuais, com certeza não vale.
>

> >> abs
>
> >> Alexandre Valente
> >> MCSE+I, MCSD, MDCBA, ITIL, CSM
> >> agvalente.wordpress.com
>

> >> 2009/11/5 Vinicius Quaiato <vinicius.quai...@gmail.com>

>
> >> @Rafael
>
> >>> Eu acho bastante sensato o posicionamento do autor.
>
> >>> Por que?
>
> >>>> Não testar será ainda mais custoso?
> >>>> A resposta errada é sim.
> >>>> A resposta certa é talvez.
>
> >>> Eu diria que a resposta é: Não ter testes que garantam aquilo é perigoso,
> >>> não te dá garantias de futuras modificações! Logo, você perderá mais tempo
> >>> em "testes do macaco".
>
> >>>> Escrever uma porrada de testes unitários - mesmo tendo uma boa noção
> >>>> do que você está fazendo, pode sim ser pior do que não escrever nenhum
> >>>> deles.
>
> >>> Por que podem ser pior?
>
> >>>> Escreva um código limpo, expressivo e apoiado em boas técnicas.
> >>>> Especifique e garanta o funcionamento de negócio com testes de
> >>>> aceitação e integração.
>
> >>> Existem bugs que não são vistos a olho nu...
>
> >>>> TDD não é a única arma para se chegar a um bom design, documentar o
> >>>> código ou prevenir bugs.
>
> >>> Eu considero que os testes que ali estão garantem a não criação de bugs
> >>> no futuro. Mantenha-os verde e tudo está ok. Evolua o código, evolua os
> >>> testes e tudo está ok. Altere um classe, mantenha os testes verdes e tudo
> >>> está ok.
>

> >>>> E nem sempre deixar de testar é faltar com profissionalismo.
>
> >>> Não?!
>

> >>> Att,
> >>> Vinicius Quaiato.
> >>>www.viniciusquaiato.com
>
>

[Alexandre Valente]

Oi Ivan,

De fato. E a idéia é minimizar as "quebras" tanto quanto possível. Como outros colocaram aqui, não usar TDD ou testes unitários não quer dizer que vc não vá testar e não é responsável por deixar aquilo funcionando.

Ou seja, se alguém vai mexer em um legado, ele tem que saber o que está fazendo e o que pode impactar esta alteração. Eu não consigo imaginar uma cobertura de testes tão boa que vc possa mexer em legado ou regras de negócio antigas tendo a certeza que de que se ficou tudo "verde" vc não vai ter problemas. Nem que alguém, de ler a especificação implícita em um teste, entenda o que aquela regra de negócio faz sem entender o negócio em si. 

Logo, se vc tem que entender o que está fazendo, teste automatizado ajuda mas não é o mais relevante. E se vc considerar que fazer teste automatizado é um custo adicional, então pode não fazer sentido gera-los por gerar (ainda mais q vc não pode confiar somente neles). Ou seja, apesar de ajudar, não acho que o que ajuda economiza mais do que o que foi gasto pra fazer a ajuda :-).

Na prática o que a gente faz é o deixar o cliente muito envolvido no que está sendo feito. Se há uma grande alteração de regras antigas ou legado sendo feita, o melhor provavelmente é fazer um refactor geral do que arriscar quebrar muita coisa. Se a mexida for pontual, dá trabalho, e é sempre arriscado, mas é possível mexer com impacto minimo ou zero. Mas ainda neste caso, o custo de fazer isto, na minha experiencia, é menor do que o de ter feito um TDD per se (claro, que depende da equipe, como foi dito varias vezes nesta thread).

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/10 Ivan Sanchez <s4n...@gmail.com>

[Eduardo Miranda]

Exatamente! Se o desenvolvedor é senior o suficiente pra ter estas dúvidas e saber se é necessário ou não testar, ele provavelmente já está fazendo o código correto pro cenário dele. E aí então pra que perder tempo com testes?

 

Continuo não entedendo como realmente funciona o seu processo, porque as vezes vc afirma que "pensar" em todos os detalhes é trabalhoso é custa tempo, em outros momentos vc afirma  que o código já é escrito como todos estes detalhes resolvidos. Como que o desenvolvedor já sabe todos os detalhes? (Ele não pensa nisto, senão perde tempo) Está no sangue?

 

2009/11/6 Alexandre Valente <alexandre...@gmail.com>

Oi Emmanuel,

Exatamente! Se o desenvolvedor é senior o suficiente pra ter estas dúvidas e saber se é necessário ou não testar, ele provavelmente já está fazendo o código correto pro cenário dele. E aí então pra que perder tempo com testes? Se o cara não consegue nem ter estas dúvidas, ele provavelmente não vai conseguir escrever o teste correto, então, de novo, pra que testes? rsrs.

Por testes eu me refiro a testes escritos (unit tests)... Claro que fazemos isto mentalmente. Sei que estou jogando pros extremos, mas minha idéia e fazer uma oposição a uma crença crescente de que TDD é a a única e melhor maneira de programar... Discordo, acho que depende... :-).

Abs

Alexandre

2009/11/6 Emmanuel G. Brandão <egomes...@gmail.com>

Alexandre,

 

Quando você disse que a sua equipe sênior já tem muita prática e eles sabem o que terá problema ou não, eles mentalmente não estão fazendo testes? Pois é, será que quando eles inserem um código novo eles mentalmente testam todo o software? Não, é impossível concorda?

Tá então, alguma coisa seria interessante ser testada, alguma regra de negócio, alguma funcionalidade, e para isso que serve a cobertura de testes. Você vai definir até que ponto quer testar.

O seu exemplo é algo que eu provavelmente não testaria... Ou testaria já que você questionou dar um overflow no int. Tudo depende. Agora, esse seu exemplo é simplório demais, porém, você garante que o usuário não vai colocar um inteiro gigante pra dar esse overflow? Como? O desenvolvedor sempre verifica todas as possibilidades?

Ao longo do dia quantas vezes o desenvolvedor irá rodar um debugg? E se quando ele arrumar um problema conflitar em outro lugar?

A conclusão que eu cheguei quanto a testes é: se eu vou testar uma única vez o software o teste é caríssimo! Mas qual software é testado apenas uma vez?

Brandão, Emmanuel G.
CSM
blog.egomesbrandao.net

___________________________________
Ao encaminhar esta mensagem, por favor:
1 - Apague meu endereço eletrônico;
2 - Apague também os endereços dos amigos que receberam juntamente com você a mensagem, antes de enviar;
3 - Encaminhe como Cópia Oculta (Cco ou BCc) aos seus destinatários. Dificulte assim a disseminação de vírus, spams e banners.

2009/11/6 Alexandre Valente <alexandre...@gmail.com>

Oi Felipe,

Não concordo muito não. Primeiro porque vc tem overhead de vc definir muito bem esta "especificação". E embora muitos falem que não, eu acho que fazer uma spec pra qqer coisa é um overkill. Imagina, vc vai fazer uma função trivial int Mult(int a,int b) { return a * b;}. Trivial certo? Escrevi "on the fly", em segundos. Se eu fosse fazer TDD disto iria primeiro escrever o teste... aí tentar imaginar como eu quero que isto funcione e como eu espero que isto quebre. O que acontece se eu passar ints de maneira que dê overflow? O que acontece se fo uma aplicação muti-thread? Como os erros devem ser retornados. Segundos vão virar vários e vários minutos.... Ou seja, TDD tem o potencial de tornar qqer coisa, por mais simples que seja, em um monstrinho! :-). E se vc for fazer o simples, que é testar se o resultado = a * b, isto seria completamente inútil (qual a chance do comp "errar" na conta? rsrs). Ou seja, pra coisas simples, ou complica sem necessidade ou é inutil., Pra coisas complexas, complica e muito... E pior, se vc vai fazer pra algumas coisas e pra outras não, qual o critério de decisão? No final, vc pode ter erros nesta fase tbm, e aí todo o seu esforço é questionávellll

Assim, vale a pena? Depende muito do sistema, do nivel que se quer de testes automatizados e etc... De repente, como o Carlos colocou, isto é uma ferramenta de marketing já que o cliente fica feliz de ver um monte de luzinhas verdes ao final de uma iteração..... Os meus com certeza não querem nem saber disto e querem é o software funcionando. :-)

E ainda no lance de especificação, usar testes para descrever é complicado... Sendo uma "linguagem de especificação", o desenvolvedor tem que ser treinado pra isto, pra pensar nos casos de erros, para não fazer só o lugar comum do caminho mais fácil etc... Possível? Claro, como falei conheço gente que faz isto muito bem. Mas para todos? Dificilmente. E eu sei que é muito caro treinar alguem pra trabalhar desta forma.

Portanto, sim, pra mim no final TDD is all about tests, ainda que vc chame isto de "especificação"  :-). E seu uso, como qqer metodologia ou ferramenta, deve ser avaliado caso a caso.

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/6 Felipe Borges <felip...@gmail.com>

Eu acredito que TDD nao se resume somente a testes, ele influencia num entendimento maior dos requisitos e funcionalidades do sistema por parte dos desenvolvedores, vcs estao comentando sobre TDD como se fosse somente testes e mais testes, em um post do Giovanni Bassi (http://unplugged.giggio.net/unplugged/post/TDD-nao-existe.aspx) tem uma visao interessante sobre isso: "Um nome mais adequado seria Specification Driven Development, ou Specification Driven Design (SDD)."

Esta é minha opiniao.

[]'s

2009/11/6 Vinicius Quaiato <vinicius...@gmail.com>

Eu não entendo esse papo de "testes são caros", sinceramente.

A verdade é que o cliente JÁ ESTÁ PAGANDO por isso, no entanto nós não estamos fazendo isso.

O cliente já paga por um software testado, sem erros e que funcione como ele espera. Porém nós cobramos isso e não entregamos isso.

Att,

Vinicius Quaiato.

www.viniciusquaiato.com

2009/11/6 Carlos Garcia <carlosga...@gmail.com>

Minha opinião? Testes são caros... quem paga? O cliente! É um investimento que ele está disposto a fazer pela qualidade do produto que ele está comprando, se o cliente não quiser pagar os testes, eu não vendo o projeto. Mas TODOS os clientes ficam muito empolgados quando eu falo que o software dele pode ser testado de forma AUTOMATICA depois de qualquer alteração.

Apoio o TDD!

2009/11/6 Alexandre Valente <alexandre...@gmail.com>

Oi Vinicius,

Detectei um leve tom de ironia... :-). Mas muito longe disto. A equipe é senior, só isto. :-)

Eu sei que o que eu escrevi vai contra o que muitos "papas" falam. Mas eu realmente questiono muito TDD como algo que todos deveriam usar e como sendo algo que é benéfico sempre. Mas ok, continuo mantendo uma mente aberta e vou continuar fazendo análises sobre isto. Mas confesso que fiquei feliz de ver que não sou só eu que penso assim! :-)

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/6 Vinicius Quaiato <vinicius...@gmail.com>

Oi Alexandre,

Não vejo que o tempo de dev. com TDD seja maior, não vejo mesmo. Como já foi dito, se você não escreve testes, acredita que o código esteja pronto. De fato em algumas situações ele estará mesmo, mas na grande maioria das aplicações comerciais, com regras de negócios complexas (sempre existem), com objetos que interagem entre si gerando outros objetos e desencadeando comportamentos, etc, o debug é deveras lento e complicado, principalmente em se tratando de aplicações web, web services e services.
O tempo de debug é muito superior ao tempo de um teste sendo executado.

Entendo que este seja o seu caso, e talvez você e sua equipe se encaixem no que o Kent Beck diz ser um "genius", e isso é realmente muito bom.
No entanto não acho justo você dizer que TDD eleva o custo e o tempo de desenvolvimento, ainda que isso se aplique à sua equipe.

Se sua equipe não consegue escrever testes simples, de baixa granularidade e dependência, talvez tenha algo errado aí, mas não quero questionar suas capacidades, lendo seu blog vejo que realmente vocês são bons.

Acho que, pelo menos eu, vou parar por aqui. Estamos quase caindo na guerra santa da outra thread, hehehehe.

Att,
Vinicius Quaiato
www.viniciusquaiato.com

Twitter

2009/11/5 Alexandre Valente <alexandre...@gmail.com>

Oi Vinicius,

Como eu falei, este é o meu caso. Com certeza não deve ser o de outros. Mas no meu caso, quando eu vou fazer uma rotina com TDD, o tempo é maior em qualquer cenário. Se a rotina é simples, não faz sentido fazer o teste pois eu consigo debugar muito mais rapidamente do que se eu escrever um teste antes pra pegar todos os possiveis erros (e não, não tenho probelmas no futuro, como falei minha equipe é pequena e só de seniores, assim são todos capazes de fazer refactors sem quebrar muita coisa ... e mesmo o custo de eventuais quebras é menor do que o de TDD sem si).

Se a rotina é complexa, projetar o teste antes leva tempo. Além de eu ter que pensar em quais casos eu tenho que montar pra tentar quebrar o código (os casos simples obviamente não servem pra quase nada), como o design é orientado ao teste bem sucedido, muitas vezes eu gasto um tempo grande refatorando a rotina em conforme ela vai sendo criada pra atender o teste. Quando eu parto pra rotina primeiro, em uma abordagem estruturada, o design quase sempre é correto da primeira vez. Ou seja, qto mais complexa a rotina, mais rápido eu faço sem TDD, simples assim.

Isto sem falar em treinamento de equipe. É muito raro encontrar alguém que seja produtivo usando TDD (eu só conheci um em toda minha carreira). E treinar alguem pra usar TDD é muito, muito caro.

Então, como falei, no meu caso TDD é sempre ruim, do aspecto de produtividade (e na qualidade, o que produzimos hoje é bom o suficiente). Claro que eu uso testes em alguns cenários, quando a rotina é complexa, quando ela é muito crítica (e é importante ter um teste unitário), como ferramenta de debug em situações complexas. Mas TDD por TDD, nos meus projetos atuais eu não acho que valha a pena.

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/5 Vinicius Quaiato <vinicius...@gmail.com>

@Alexandre,
Por que você diz que testar é caro, ou praticar TDD é caro? Não entendo como isso pode ser mais caro.
Na minha singela utilização de TDD tenho percebido que é mais rápido, prático, e garante muito mais do que simplesmente o teste do macaco.

Para mim caro é perder tempo, e não vejo perda de tempo com TDD.
Além do TDD ser rápido e prático, os testes permanecem lá, ao contrário dos testes do macaco.

Att,
Vinicius Quaiato.
www.viniciusquaiato.com

2009/11/5 Alexandre Valente <alexandre...@gmail.com>

Oi,

Sou mais um do "contra". No meu caso especificamente, eu concordo completamente com o autor. Testar (bem) é caro, e com certeza diminuiu minha produtividade. (Já imagino a facção fundamentalista TDD preparando para o fuzilamento! rsrs). E sim, conheço TDD, já vi pessoas que fazem isto muito bem trabalhando e eu mesmo já usei, da maneira prevista, em vários cenários para avaliar. E minha conclusão é a mesma do autor, em vários cenários isto pode se mostrar inviavelmente caro.

Significa que TDD é ruim? Óbvio que não, estou falando do meu caso em específico.... Claro que em equipes onde várias pessoas, de níveis diferentes mexem no código e em uma diversidade de outros cenários, com cerrteza TDD é muito útil. Mas eu vou contra a opinião de vários xiitas de que TDD "is the only true way"... :-). Acredito que em times pequenos, só de seniores, a utilização de TDD vai aumentar custo sem contrapartida. E aí o seu uso tem que ser ponderado, pode ser que valha a pena, pode ser que não valha... Nos meus projetos atuais, com certeza não vale.

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/5 Vinicius Quaiato <vinicius...@gmail.com>

@Rafael

Eu acho bastante sensato o posicionamento do autor.

Por que?

 

Não testar será ainda mais custoso?
A resposta errada é sim.
A resposta certa é talvez.

Eu diria que a resposta é: Não ter testes que garantam aquilo é perigoso, não te dá garantias de futuras modificações! Logo, você perderá mais tempo em "testes do macaco".

 

Escrever uma porrada de testes unitários - mesmo tendo uma boa noção
do que você está fazendo, pode sim ser pior do que não escrever nenhum
deles.

Por que podem ser pior? 

 

Escreva um código limpo, expressivo e apoiado em boas técnicas.
Especifique e garanta o funcionamento de negócio com testes de
aceitação e integração.

Existem bugs que não são vistos a olho nu...

 

TDD não é a única arma para se chegar a um bom design, documentar o
código ou prevenir bugs.

Eu considero que os testes que ali estão garantem a não criação de bugs no futuro. Mantenha-os verde e tudo está ok. Evolua o código, evolua os testes e tudo está ok. Altere um classe, mantenha os testes verdes e tudo está ok.

 

E nem sempre deixar de testar é faltar com profissionalismo.

Não?!

Att,

Vinicius Quaiato.

www.viniciusquaiato.com

--
[]s

Carlos Garcia

--

PRABOR - Software Development - fel...@prabor.com.br
----------------------------------------------------------------
Felipe Prata L. Borges
MCT, MCPD .Net Framework 2.0: Web Applications
Contact: +55 19 9356 1355
msn: felip...@hotmail.com
skype: felipe.prabor

[Juan Pedro A. Lopes]

O que eu não entendo é o argumento "quem é sênior não precisa criar testes automáticos e/ou unitários".

Eu programo desde que tinha 10 anos de idade, programo em C++ também, que é 1e6 vezes mais complexo que C#. Programo em C# há 5 anos, e tenho certeza absoluta que preciso testar.

2009/11/10 Eduardo Miranda <dud...@gmail.com>

[Alexandre Valente]

Oi Eduardo,

Ele não tem que escrever o teste? Logo ele tem que saber todos os detalhes, não?

abs

2009/11/10 Eduardo Miranda <dud...@gmail.com>

[Eduardo Miranda]

Acho que vc não entendeu minha pergunta

 

Em um momento vc afirmou que pensar em todos os problemas e possibilidades seria um dos motivos do desenvolvedor perder produtividade com testes.

 

Em outro momento, vc afirmou que quando o desenvolvedor é senior, o código que ele escreve, já resolve todos os problemas, sem precisar de testes.

 

Minha pergunta é: Dado que o desenvolvedor não gasta tempo pensando nestes problemas como que ele consegue ainda assim escrever um código que resolve todos estes problemas?

 

2009/11/10 Alexandre Valente <alexandre...@gmail.com>

[Weverton Gomes]

Galera,

Gostaria de contribuir com a thread falando sobre o caso da nossa empresa: 

Temos uma suite de aplicações desenvolvidas em Delphi, sem testes unitários, e temos muitos problemas com alterações que quebram funcionalidades do sistema; e olha q são sistemas de pequeno e médio portes. Agora, estamos desenvolvendo um novo projeto usando .NET e TDD e estamos muito satisfeitos com o resultado. Sabemos que ainda temos muitos que melhorar com relação à qualidade dos nossos testes, mas, para nós, o retorno se faz a olhos vistos. Se perguntarmos hoje à nossa equipe e ao nosso coordenador, ninguém quer abandonar os testes.

Att,

2009/11/10 Eduardo Miranda <dud...@gmail.com>

--
Weverton Gomes de Morais
Tecnólogo em Redes de Comunicação
Desenvolvedor Delphi
Entusiasta Ruby/Rails
"Todos juntos somos fortes"

[Giovanni Bassi]

Weverton, bem legal! Esse é o feedback que recebo de todos os clientes onde introduzo TDD.

[]'s

Giovanni Bassi
Microsoft MVP, MCSD, MCPD, CSM
Arquiteto de software
http://www.giovannibassi.com

2009/11/10 Weverton Gomes <weve...@gmail.com>

[Vinicius Quaiato]

Talvez seja isso...

Tenho percebido que a aceitação ao TDD é maior entre profissionais mais novos. Tenho visto isso nos feedbacks que recebo com relação aos artigos que coloquei no meu blog.

E tenho visto isso aqui na empresa também. Isso sem falar aqui na lista e em outra lista que participo (.NET BR).

Att,
Vinicius Quaiato
www.viniciusquaiato.com

Google Talk: vinicius.quaiato

Twitter

--- @ WiseStamp Signature. Get it now

2009/11/10 Weverton Gomes <weve...@gmail.com>

[Eduardo Miranda]

Minha pergunta é: Dado que o desenvolvedor não gasta tempo pensando nestes problemas como que ele consegue ainda assim escrever um código que resolve todos estes problemas?

 

Como eu esperava fiquei no vácuo com a minha pergunta. Porque a resposta é simples, ou o desenvolvedor gasta o tempo pensando nos cenários possíveis e em corner cases, ou o código dele simplesmente não vai "automaticamente" atender todos estes casos. Por mais senior que ele seja.

 

E se ele já gasta pensando nestes cenários e executando estes cenários em debug, porque não formalizar isto em um teste unitário?

 

Acontece que a maioria dos desenvolvedores simplesmente não testa seu código. Escreve 10, 100, 1000 linhas de código, depois abre a própria UI do aplicativo e roda o cenário mais básico de todos e faz checkin.

 

Eu também seguia este padrão. Para falar a verdade, eu seria incapaz de contar as linhas de código que eu escrevi que tinham bug ou que não reagiam bem a corner cases. Quando surgia um bug, vindo do cliente ou do QA eu ainda tinha a cara de pau de dizer "isto aqui, é uma besteira, duas linhas de código está resolvido" (Pare para pensar nesta frase, vc afirma que foi incapaz de escrever duas linhas de código corretamente e ainda tira onda!)

 

A minha senioridade veio da aceitação de que eu não sou tão bom assim, que meu código geralmente é bem fraquinho, cheio de falhas. Por isto eu testo, re-testo, reviso meu próprio código 20 vezes antes de mandá-lo para code review.

 

Este é o profissionalismo que o Uncle Bob tanto prega, e que eu apóio 100%. Nós temos sim que elevar o nível de profissionalismo da engenharia de software.

 

2009/11/10 Eduardo Miranda <dud...@gmail.com>

[Juan Pedro A. Lopes]

+1

E mais uma vez, quando você começa a testar, automaticamente você percebe que é muito mais prazeroso programar com eles do que sem eles, por mais difícil que seja acreditar nisso no começo.

2009/11/11 Eduardo Miranda <dud...@gmail.com>

[Mauricio Aniche]

Oi Alexandre,

Desculpe pelo e-mail grande, mas estava sem tempo de responder no começo da thread, e agora as respostas acumularam! :)

Claro que é possível escrever um código sem erro, apenas abrindo o bloco de notas (ou sua IDE preferida) e programar. Realmente não é preciso usar TDD (ou qualquer outra prática) para isso. Mas pq isso não acontece? Porquê é MUITO difícil !

A idéia de TDD é justamente tornar isso um pouco menos difícil (veja bem, não disse que fica fácil, e sim menos difícil). Outras práticas ágeis também vão pelo mesmo sentido. Programação em pares por exemplo, nada mais é do que uma revisão em tempo real do código que você escreve; se você escrever algo errado, seu companheiro está do lado e vai te avisar.

Não concordo muito com o seu argumento de uma equipe só de sêniores ser o suficiente para escrever código bom. Todos estamos aptos a errar, independente da experiência. Óbvio que quanto mais experiência você tem, espera-se que você cometa menos erros, mas mesmo assim, não dá pra falar que você não vai errar nunca.

Quanto à perda de produtividade, de que maneira isso foi medido? Não consigo entender como você pode ter TANTA perda de produtividade utilizando TDD. Imagino que após escrever um trecho de código, você testa. Suponha que esse código escrito possua duas instruções if/else ... Esse simples trecho de código produz 4 possíveis diferentes branches, e você obviamente testa os 4. Testar isso de maneira manual é difícil e consome muito tempo. Supondo então que você tenha alguma ferramenta automática para testes (tipo aquela da AutomatedQA, ou coisa parecida), isso já ajuda e fica um pouco mais rápido. Mesmo assim, alguns estudos [1] já mostraram que programas produzidos sem TDD comparado aos produzidos com TDD tendem a apresentar mais defeitos.

Outros estudos [2] já mostraram também o efeito de TDD em termos de qualidade de código, onde códigos produzidos com TDD tendem a apresentar um nível de acoplamento MUITO menor, complexidade de métodos menor (medido através de métricas já conhecidas como complexidade aciclomática, etc), e tendem a utilizar melhores conceitos de OO (difícil de medir, mas está lá). Outros fatores positivos podem ser encontrados, como menor tempo gasto em debugging (e isso aumenta a produtividade),  motivação maior do programador (técnicas como ping-pong pairing são bem divertidas!), etc.

Embora em minha opinião esses experimentos foram conduzidos em grupos muito pequenos (e eles mesmos sabem disso, vide seção de problemas nos artigos), acho que já é um resultado válido). Na minha dissertação de mestrado, estou trabalhando em experimentos maiores e pretendo divulgar os resultados ASAP.

Outra coisa que acho muito difícil sem uma bateria de testes automatizados são testes de regressão. No meu caso, esse foi um dos principais motivos para que eu adotasse TDD. Certa vez em um pequeno projeto que estava fazendo e decidi usar TDD para aprender, a primeira versão ficou legal pra caramba. Depois de algum tempo funcionando, o cliente me pediu uma alteração super simples (na minha cabeça já veio a implementação: era apenas UM if).  Eu fui lá todo feliz colocar o if. Gastei 10 segundos. O novo teste que havia escrito passou.. Mas pasmém: quebrei uns 8 testes antigos. E realmente, o simples if que escrevi quebrava outras regras de negócio! No fundo, não era tão simples assim! A lição é: mesmo que a alteração seja a mais simples possível, você ainda assim pode quebrar coisas. Como você faz na sua equipe? Supondo que você execute os testes manuais, a cada release você põe sua equipe de testers para re-testar tudo (isso deve custar caro!)? Supondo que você utilize a mesma ferramenta que citei acima, você roda só final, e aí aparecem 20 bugs de uma vez, não fica mais difícil (também custa caro!)?

Sobre ensinar TDD a alguém, realmente não é tarefa muito fácil. Mas também não é impossível. O Livro do Kent Beck (TDD by example) é muito didático. Outra boa prática é frequentar dojos! Se não me engano você é do Rio, correto (vi pelos seus tweets ;)? O pessoal da globo.com organiza dojos frequentes, se não me engano!

[1] Driving Software Quality: How Test-Driven Development Impacts Software Quality (http://www2.computer.org/portal/web/csdl/doi/10.1109/MS.2006.157)
[2] On the Influence of Test-Driven Development on Software Design (http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1617340)

Abraços,
Mauricio Aniche

2009/11/10 Alexandre Valente <alexandre...@gmail.com>

[Alexandre Valente]

Oi Eduardo,

Desculpe pela demora em responder.

Discordo. Pensar nos cenários automaticamente é parte do trabalho. Escrever testes unitários não é. Ou vc escreve e codifica tão rápido quanto pensa? :-)

No meu exemplo acima eu coloquei um caso ultra simples, onde escrever a função (e pensar nos casos de problema) demorou menos de 10 segundos... Escrever o teste com certeza seriam vários minutos.

Com pessoas que não fazem TDD sempre, o impacto é muito significativo (eu sei por experiencia). Estamos falando de pelo menos metade da produtividade normal (claro, isto usando TDD corretamente, não fazer um teste qualquer só pra falar que é TDD).

Retomando uma resposta anterior, a impressão que se tem é que "os mais novos" gostam mais de TDD. Até pode ser (como falei, eu acho fundamental a formação em TDD para que um dia seja uma prática mais produtiva), mas não acho que é só isto. Os mais novos normalmente não estão "ainda" ligados à parte da gestão de projetos, de venda e de estarem envolvidos na questão do projeto dar resultado financeiro (lucro), e não somente ser bem feito. Acho que isto tbm explica em parte este fenomeno, já que os mais seniores são bem mais ponderados no uso de metodologias ou ferramentas, justamente por isto.

Novamente, acho TDD interessante, e muito útil em vários cenários. Somente não pra todos. No meu caso específico, usar TDD significa diminuir produtividade. E depois desta thread, tenho conversado com outras pessoas, seniores tbm... E vi que minha opinião nào é tão isolada assim! :-)

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/11 Eduardo Miranda <dud...@gmail.com>

[Alexandre Valente]

Oi Maurício,

Não tenho conhecimento de nenhum estudo formal de TDD x produtividade. Se tiver alguma referencia, passe por favor.

Como falei no email anterior, o impacto é causado por se ter que escrever testes em código. Como muitos citaram aqui, escrever um caso de teste significa escrever código. Logo ele tem que ser bem feito, tem que testar todos os casos, tem que ser debugado etc. Isto leva tempo! Outro ponto que é subjetivo é a forma que o TDD impoe. Fazer a rotina "certa" no meu caso (e de muitos outros) é muito mais rápido do que escrever o teste e ir refatorando a rotina (eu sei que pra outras pessoas, isto não é assim).

E vc pode comprovar isto na prática. Pega o exemplo que eu citei antes, uma simples função de multiplicar. Escreva o código com o sem TDD e meça o tempo. Só pela quantidade de código escrita vc já perde mais tempo (assumindo que vc consiga escrever o código de teste completo e sem erros da primeira vez). A questão é qu "pensar" nos casos de exceção não quer dizer que vc tenha que escrever os casos de teste ou mesmo debugar pra ver como é (vc sabe o que é um overflow exception, não precisa debugar pra ver ele acontecendo). Por isto que pessoas seniores são fundamentais.

O argumento de TDD é que isto vai diminuir custo de manutenção e aumentar qualidade. E é aí que eu questiono, pois não vejo isto hoje com minha equipe. A gente não perde mais tempo dando manutenção nos nossos sistemas porque a gente não tem os casos de testes montados. Claro que todos vamos errar. A questão é o custo pra corrigir. Se usar TDD fosse diminuir meu custo, tenha a certeza que eu já estaria usando. A questão é que todas nossas experiencias não comprovaram isto na prática, foi justamente o contrário. Nosso código é bom, a qualidade já é boa naturalmente (de novo, específico da equipe). Então o ganho de qualidade potencial não consegue justificar o custo adicional.

Acho que tudo se resume a equipe. Claro que tem mais equipes melhores e mais produtivas com TDD. E existem outras tão boas quanto sem TDD. Meu argumento neste post, que acho que foi perdido não é que eu seja contra TDD (pelamorededeus, muito ao contrário). Simplesmente sou contra a falácia que só quem usa TDD é bom programador ou faz bom software... ;-)

abs

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com 

2009/11/11 Mauricio Aniche <maurici...@gmail.com>

[Marcelo Zeferino]

Sou novo nesta lista, mas estou acompanhando e gostaria de adicionar um caso...

 

Há pouco tempo estava falando com um colega sobre um sistema que estavam desenvolvendo. Inclusive, achei bem legal. Daí, rolou o diálogo:

 

EU: Legal, mas e como está sua cobertura de testes?

ELE: É... não temos testes. A gente faz e passa para uma pessoa específica do cliente testar...

EU: Ah sim. Mas essa pessoa está na equipe tb? (o desenvolvimento acontece alocado no cliente)
ELE: Não não. É um cara que só aparece de vez em quando aqui. Aliás, não vem desde o mes passado por causa de uma dispensa.

EU: E como sabem se está certo ou se é  o que o cliente quer?

ELE: Tem uns caras que testam e quando este "TESTER" vêm, ele usa o sistema e testa...

 

Enfim, eu não consigo dormir tranquilo com isso. Já fiz coisa parecida, mas hoje em dia vejo mais como seguir assim...

 

Atuo desde 2006 com sistemas para pesquisas em saúde e se não tiver como garantir que as coisas estão certas (e nem sempre o certo é mesmo certo - rs), pode ter gente tomando medicações erradas, podendo até vir a óbito...

 

Não me considero radical ao ponto de dizer que só quem usa TDD é bom ou faz bom software, mas acho que, seja com ou sem TDD, devem existir testes e, de preferência, automatizados. E isso já se falava bem antes de TDD (que por sua vez já não é coisa nova).

 

Aliás, IMHO, não serão só os testes que definirão a qualidade do código. A equipe, os envolvidos (ou comprometidos), práticas e muitas outras coisas...

 

A[]´s

Marcelo Zeferino
http://www.linkedin.com/in/marcelozeferino

[Mauricio Aniche]

Oi Alexandre,

Nos artigos que citei acima, tem um pequeno estudo (ambos são formais) sobre produtividade. Talvez valha a pena ler!

Não sei se entendi bem quando você disse sobre "forma que o TDD impõe". Você diz respeito aos baby steps? Só lembrando que o próprio Kent Beck diz que você pode definir o tamanho do seu step. No livro dele, não me recordo quais eram as palavras exatas, mas ele, em um exemplo (e era beeem baby step!), diz algo como: "Eu programo assim o tempo todo? É claro que não. Mas fico feliz em saber que posso ir devagar assim quando tiver necessidade".

No seu exemplo da função multiplicar(), ela pode ser tão simples ou tão complexa quanto você queira. Se você quer escrever testes para todos os casos de exceção, você vai testar isso também de forma manual, não vai? Afinal, você pensou em um possível problema, você não vai deixar de testar, correto? Talvez eu não tenha entendido também, pq o exemplo é muito simples. Imagine o seguinte problema (igualmente simples, mas que permite ir um pouco mais a fundo!): Você tem que calcular o valor do imposto da seguinte forma: se o valor for menor que 5k, o imposto é 5% do valor. Caso contrário, é 7%.

@Test
public void valoresMenoresDe5KTemImpostoDe5PorCento() {
  assertEquals(new CalculadoraDeImposto().calcula(4000), 4000*0.05);
}

Nesse momento implemento meu calcula():
calcula(double valor) { return valor*0.05; }

@Test
public void valoresMaioresQue5KTemImpostoDe7PorCento() {
  assertEquals(new CalculadoraDeImposto().calcula(7000), 7000*0.07);
}

Meu calcula() agora:
calcula(double valor) { return valor<5000?valor*0.05:valor*0.07; }

E pronto... Se eu pedisse pra vc implementar essa função, você provavelmente chegaria em um código parecido dessa minha calcula() final, e depois rodaria o programa e forneceria duas entradas para testar (gastando mais tempo que eu pra testar). Provavelmente também testaria o valor 5000, pois sabemos que muitos erros ocorrem na análise do valores nos limites [1]. Então teria um teste lá pra garantir que se a entrada fosse 5k, o imposto seria 7% também. Veja também que não estou testando se a multiplicação funciona corretamente (acho que alguém levantou isso em um e-mail anterior), e sim a regra de negócio.
Agora que vi que tudo funciona, posso refatorar a vontade (não gostei desse meu if ternário, por exemplo)! Se eu fizer alguma besteira, meu teste avisa.

Veja que não perdi muito mais tempo que na abordagem tradicional, e ganhei testes automatizados pra essa funcionalidade.

Acho que não ficou claro pra mim ainda como você faz seus testes! Poderia explicar um pouquinho? Se já explicou acima na thread, eu não estou lembrado, me avise que eu procuro melhor! :)

PS: Podem haver erros no meu exemplo acima, não os testei. Mas vale a idéia! :)
PS2: Pena que só li seu e-mail agora... Estava no Rio sábado, podíamos ter marcado um chopp pra discutir isso! :)

[1] Introdução ao Teste de Software - Delamaro, Maldonado, Jino. 1a edição. Campus-Elsevier.

Abraços,
Mauricio Aniche

2009/11/11 Alexandre Valente <alexandre...@gmail.com>

[Alexandre Valente]

Oi Mauricio,

Vc avançou exatamente no meu ponto. Olha a quantidade de código q vc gerou. E seguindo o meu exemplo, eu sou sênior (pra saber o q poderia dar errado com esta função), conheço o negocio pra saber q em todos os casos esta função será usada para números pequenos). Então pra que testar isto? Perda de tempo completa, certo? Ou vc acha q um mult pode falhar?

Ou seja, aplicar TDD sem bom senso pode gerar perda de tempo, ainda mais com pessoas inexperientes.... Se para um caso simples como este é verdade, imagina pra mais complexos... :-)

Abs

Alexandre Valente

[Eduardo Miranda]

Discordo. Pensar nos cenários automaticamente é parte do trabalho. Escrever testes unitários não é. Ou vc escreve e codifica tão rápido quanto pensa? :-)

 

Mas vc não só pensa, também os executa debugando, pelo menos foi o que entendi, caso contrário caimos naquela situação do desenvolvedor que entrega código sem nenhum teste, acredito que este não seja o caso aqui.

 

Então vc tem que pensar nos cenários, executar em debug e verificar o resultado.

 

O processo de desenvolvimento é sempre iterativo, então a cada mudança no código, vc repete, ou pelo menos deveria, os três passos acima.

 

Se vc fizer isto 3 vezes durante todo o processo de desenvolver a aplicação, é garantido que teria valido a pena automatizar. O tempo de re-executar os passos seria muito mais rápido e o risco de vc esquecer um dos cenários simplesmente não existe.

2009/11/11 Alexandre Valente <alexandre...@gmail.com>

[Mauricio Aniche]

Oi Alexandre,

Você achou que eu escrevi muito código? Eu não achei! São basicamente 6-8 linhas de código de teste, que vc escreve rápido, e traz um ganho eterno (nossa, fui profundo)!

E veja que não estou testando a multiplicação; nela eu confio! Eu não confio é na minha função calcula(), não sei se ela vai realmente multiplicar pelos fatores corretos!! Essa minha simples função tem 2 branches possíveis. Agora imagina uma mais complexa, não vejo muito como garantir que ela funcione sem automatizar o teste (mesmo com o teste já é difícil garantir, imagina sem!).

Você pode contar um pouco de como funcionam os testes aí?

[Alexandre Valente]

Oi Eduardo,

Claro que o bom senso é empregado pra tudo. O desenvolvedor tem que entregar tudo funcionando. Se ele se garantir sem debugar, excelente. Se precisar testar um cenário, aí ele escreve um unit test, claro. Em muitos casos um teste de interface dá conta de todo o processo (e aí vc ganha tempo também com uma série de outras coisas).

No nosso caso a gente tenta manter as regras pequenas para que realmente as coisas sejam sempre o mais simples possivel. Acho que estes são os principios que eu sigo:. Manter tudo o mais simples possivel, automatizar o que é repetitivo, fazer com cuidado o que é complexo (poucas coisas) e aplicar ferramentas e metodologias conforme o caso.

abs

Alexandre Valente

2009/11/11 Eduardo Miranda <dud...@gmail.com>

[Alexandre Valente]

Mauricio, olha o que vc está escrevendo! :-) A função calcula é uma multiplicação? Vc não consegue ver isto pelo código? Como vc pode não confiar no que ela retorna? Em que cenário ela falharia? E se vc tivar (ou colocar) o overflow na jogada, que outro problema vc vc?

Por menor que seja o que vc escreveu isto é esforço inútil. Isto pra uma multiplcação! :-) Imagine o que vc faria com uma funçao completa, com operaçòes aritméticas, concatenação de strings, alocação e desalocação etc... Perceba que o TDD levado a extremos pode fazer com que vc escreva centenas de linhs de código pras funções mais simples..... É só isto que eu estou falando, bom senso.... Se é bom senso, aplicar TDD como um todo tbm é questão de bom senso... .:-)

Abs

Alexandre Valente

[Juan Pedro A. Lopes]

Alexandre, você já desenvolveu um projeto do início ao fim usando TDD?

Digo isso pois parece que, para todos que não usam, TDD não faz muito sentido. Admito que meu primeiro intuito ao usar TDD foi estar na crista da onda mesmo, mas hoje em dia eu não consigo imaginar minha vida sem.

O objetivo de escrever testes para a função descrita pelo Maurício não é testar a multiplicação. Testes não tem como objetivo SOMENTE verificar se você programou corretamente. Imagine que, no futuro, durante a implantação, um outro desenvolvedor tenha que adicionar uma funcionalidade à sua função. Ela ainda está simples, mas pode ser que fique bem complexa. Como garantir que o comportamento inicial dela seja mantido, e os novos comportamentos adicionados estejam certos?

2009/11/11 Alexandre Valente <alexandre...@gmail.com>

[Vinicius Quaiato]

Acho que chegamos no seguinte resumo da ópera:
Se você quer construir um software no qual seja mais seguro realizar alterações futuras use TDD.
Se você quer construir um software com uma arquitetura simples e que seja segura para alterar no futuro use TDD.

Se você quer depender única e exclusivamente da sua equipe e do debug não use TDD.

Acho que em resumo tudo o que foi dito é isso.

Att,
Vinicius Quaiato
www.viniciusquaiato.com

Google Talk: vinicius.quaiato

Twitter

--- @ WiseStamp Signature. Get it now

2009/11/11 Juan Pedro A. Lopes <zero...@gmail.com>

[Leo D]

Pois é, nesses extremos tem developer que fica testando concatenação de strings, classes do Framework... mesmo que tomem 3 linhas de código, isso é tempo perdido, porque não testa nada relevante.

Só pra constar, eu já tive boas experiências com testes de unidade. Eu gostei de usar teste de unidade quando desenvolvi um sistema para hipotecas, havia um método para seleção do "broker" que tinha entradas e saídas de negócios bem definidas. A seleção do broker variava com o "peso" dado pelo administrador, e com a afinidade do broker a alguns critérios (preferência de contato do usuário diurno ou noturno, valor da hipoteca alto ou baixo, categoria prime ou subprime, etc). O teste de unidade foi bem útil, porque existiam várias permutações possíveis, e testar usando a interface seria mais lento.

Eu acredito que adotar testes de unidade na medida certa pode ser uma boa, só acho que estabelece-los como regra (e ainda almejar 100% de cobertura), ao menos pra mim não funciona, porque você acaba escrevendo um monte de testes desnecessários, que vão quebrar quando você precisar refatorar o código. Eles vão tirar sua agilidade e produtividade. Fazendo uma caricatura, vira aquele cenário do artigo original, o ciclista profissional competindo com bicicleta com rodinha para crianças.

Então pra mim "depende" mesmo,

- da experiência do usuário com desenvolvimento
- da familiariadade ou não com a plataforma e o sistema
- que métodos / funcionalidades se está testando

[]s

[Alexandre Valente]

Claro Juan.

Exato. Mas olha só! Vale o preço de vc pagar pra fazer estes testes pra que um dia se outro desenvolvedor pegar ele não tenha dúvida? Neste caso, se um desenvolvedor tiver duvida sobre que erros esta funçao poderia retornar, ele não estaria na minha equipe!! rsrsrs

Este é o meu ponto. TDD blindly gera custo, Simples assim. Estes ultimos emails nesta thread reforçaram ainda mais este ponto! :-)

Mas ok. Cada caso é um caso.

Abs

Alexandre

2009/11/11 Juan Pedro A. Lopes <zero...@gmail.com>

Alexandre, você já desenvolveu um projeto do início ao fim usando TDD?

[Alexandre Valente]

Faltou uma. Como qqer coisa, use TDD com bom senso. Se houver motivos que justifiquem faça uso (seja pelo negócio, seja pela equipe). Se não, não! :-)

Abs

Alexandre Valente

2009/11/11 Vinicius Quaiato <vinicius...@gmail.com>

[Emmanuel G. Brandão]

Nós poderíamos fazer dois dojos em paralelo, um usando TDD e o outro não... E analisáriamos a performance das soluções.

Brandão, Emmanuel G.
CSM
blog.egomesbrandao.net

___________________________________
Ao encaminhar esta mensagem, por favor:
1 - Apague meu endereço eletrônico;
2 - Apague também os endereços dos amigos que receberam juntamente com você a mensagem, antes de enviar;
3 - Encaminhe como Cópia Oculta (Cco ou BCc) aos seus destinatários. Dificulte assim a disseminação de vírus, spams e banners.

2009/11/11 Alexandre Valente <alexandre...@gmail.com>

[Juan Pedro A. Lopes]

É complicado, pois o objetivo do dojo não é solucionar o problema. É aplicar/ensinar TDD.

2009/11/11 Emmanuel G. Brandão <egomes...@gmail.com>

[Vinicius Quaiato]

Estamos caindo em uma 'guerra santa'.

Acho que não é pra tanto.