O grupo no qual você está postando é um grupo da Usenet. As mensagens postadas neste grupo farão com que o seu e-mail fique visível para qualquer pessoa na internet.
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.
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?!
> 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
> Chris Ashton, funcionário da MS, escreveu o seguinte artigo em seu blog:
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.
> 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?!
> 2009/11/5 Leo D <l...@codigofluente.com.br > <mailto: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 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.
> 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
> 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?!
>> 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
>> Chris Ashton, funcionário da MS, escreveu o seguinte artigo em seu blog:
> 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.
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 “*j**ust 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.
>> 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.
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?
>> 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.
> 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.
> 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
> Chris Ashton, funcionário da MS, escreveu o seguinte artigo em seu blog:
> "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.
> 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.
>> 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
>> Chris Ashton, funcionário da MS, escreveu o seguinte artigo em seu blog:
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.
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.
> 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.
> 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.
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.
>> > 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.
> > 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?
@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.
> 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.
>> 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.
> 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.
> >> > 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.
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.
> @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.
>> 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.
>>> 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.
> 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.g.vale...@gmail.com>
> 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.
>> @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.
>>> 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.
>>>> 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.
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. :-)
> 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.g.vale...@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.
>>> @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.
>>>> 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.
>>>>> 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.
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.
"
> 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.
>> @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.
>>> 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.
>>>> 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 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.
> 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.
> "
>> 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.
>>> @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.
>>>> 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.
>>>>> 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 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.
>> 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.
>> "
>>> 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.
>>>> @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.
>>>>> 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.
>>>>>> 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.
|
