Onde existe TDD de verdade no Brasil?

[Daniel Freire]

Pessoal,

hoje fui questionado na empresa que eu trabalho, ao falar de TDD.
Escutei o seguinte:

"TDD vai morrer na literatura. Qual empresa você conhece que
implementa isso?". E eu fiquei sem saber responder, pois na realidade
nunca vi alguma empresa que adota essa regra na prática. Any??

Abs.,

--
Daniel C. Freire
Analista Desenvolvedor
MCP, MCTS - Web Applications 2.0
(31) 8467-2331

[Gustavo Badke]

Primeiro, fale para seus colegas de trabalho ficarem mais antenados com práticas de software

O TDD tornou mais famoso no manifesto ágil e vou te falar q se não todas mas 98% das equipes ágeis usam TDD, praticam TDD, amam TDD, não desenvolvem sem TDD, a maior felicidade de desenvolver é usar TDD.

Para dar um exemplo de uma empresa. A propria Microsoft usa muito SCRUM e muito TDD.

Apresente para seus colegas de trabalho o Coding Dojo http://bit.ly/99Nmrc, se eles falarem q não valem a pena, está na hora de trocar de equipe.

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

[Juan Pedro A. Lopes]

Se você se refere a TDD by the book, vai terminar no mesmo problema que RUP. (quase) Ninguém aplica RUP de verdade.

Se você se refere a automated testing, posso dizer que é a melhor coisa do mundo. Como diria o Vinicius Teles, "não dá pra você se achar minimamente sério em desenvolvimento de software se você não desenvolve testes" link.

No mais, aqui pra você, ó.

2010/6/18 Gustavo Badke <guri...@gmail.com>

--
Kind regards,
Juan Lopes

http://qrcode.juanlopes.net

[Diego Correa Gonçalves]

E porque precisa ser no Brasil?

Cite empresas internacionais, porque não?.

Você não começa a fazer alguma coisas só quando o seu concorrente direto começa também. 

É preciso ter uma visão mais ampla de mercado.

> Date: Fri, 18 Jun 2010 20:09:48 -0300
> Subject: [dotnetarchitects] Onde existe TDD de verdade no Brasil?
> From: danie...@gmail.com
> To: dotnetar...@googlegroups.com

> --
> Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
> Para postar envie uma mensagem para dotnetar...@googlegroups.com
> Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
> Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

---

TRANSFORME-SE EM PERSONAGENS ENGRAÇADOS COM O SITE DE I LOVE MESSENGER. VEJA COMO.

[Rodrigo Vieira]

Antes de mais nada não entendi a parte de "no Brasil", afinal
desenvolvimento de software não depende de nacionalidade (e de qq
forma a gente sempre termina copiando o que se faz lá fora há anos)

Aqui vai uma pesquisa do Dr Dobbs sobre o assunto (essa é de 2007 mas
se vc procurar deve achar mais recente)

http://www.drdobbs.com/architecture-and-design/200001986

- Rodrigo

2010/6/18 Daniel Freire <danie...@gmail.com>:

[Ezequiel Bertti]

na puc do rio tem um curso de TDD

2010/6/18 Rodrigo Vieira <rodr...@gmail.com>

--
Ezequiel Bertti
E-Mail: ebe...@gmail.com
MSN: ebe...@hotmail.com
Cel: (21) 9188-4860

VÁ PARA BÚZIOS!!!
http://www.agh.com.br/
Ane Guest House

[Gustavo Badke]

O proprio Giovanni Bassi, lider deste grupo usa e muito. Ramom Durães tbm

[Vinicius Quaiato]

De fato pode ser que algumas empresas não utilizem.

Isso não é culpa do TDD, é culpa da péssima qualidade de serviços prestados pela maioria das empresas, que ainda possuem um "mind set" totalmente retrógrado(e errado) com relação ao que é desenvolver software.

Mesmo dentro destas empresas, muitos bravos e heróicos guerreiros utilizam TDD individualmente no seu dia-a-dia. 

Claro, um ambiente desfavorável acaba não proporcionando uma vivência de 100% no TDD.

Agora fora estes casos, tenho certeza que várias pessoas que estão aqui na lista trabalham em empresas que sim, utilizam TDD no seu dia-a-dia.

Como foi dito, a maioria das equipes que utilizam métodos ágeis, no geral utilizam TDD, é quase que cultural.

Agora, para o pessoal da empresa que disse isso só resta lamentar.

Eu jamais deixaria de fazer algo que é bom, em virtude de "ninguém fazer". 

E outra, se você é sério em realizar seu trabalho, considere TDD e também BDD, independente de ser uma cultura da empresa.

Att,

Vinicius Quaiato.

http://viniciusquaiato.com

2010/6/18 Gustavo Badke <guri...@gmail.com>

[Juan Pedro A. Lopes]

Bravo, Vinicius.

+1 

2010/6/18 Vinicius Quaiato <vinicius...@gmail.com>

--

[Alexandre Valente]

Oi Vinícius,

Faz tempo que eu não polemizo aqui na lista, ainda mais sobre este assunto, mas não resisti! :-) Como vc sabe, discordo de vc na teoria, e na prática não é verdade que a maioria das equipes que utilizam métodos ágeis utilizam TDD. Muito ao contrário aliás, todas as equipes ágeis que eu conheço, de várias empresas, NÃO utilizam TDD no seu dia-a-dia.

O que eu vejo sim é que as equipes ágeis se preocupam mais com testes, mas sem usar TDD, simplesmente aplicando testes com um determinado grau de cobertura nos pontos mais críticos ou importantes do código ou usando TDD em na construção de alguns artefatos mais complexos. Na WhiteFox trabalhamos desta forma. 

Sem entrar no mérito, o que eu vejo é que TDD é utilizado de maneira consistente somente por alguns profissionais ou consultores, como vc falou, de maneira individual. Mas no geral é muito raro ver alguém usando de forma geral e especialmente raro (eu nunca vi) ver um time inteiro usando sempre (não to dizendo que não exista, é só a minha experiência do que eu já aqui no Rio e em SP... se alguém conhecer algum caso eu teria vontade de em ir visitar...). Os poucos casos que eu vejo são treinamentos ou qdo algum consultor chega e diz "vamos usar", mas a prática é abandonada assim que o consultor vira as costas...

abs,

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com

www.whitefox.com.br

2010/6/18 Vinicius Quaiato <vinicius...@gmail.com>

[edmilson hora]

É pessoal!   existe um gap  entre o mundo idéal  e o mundo real!!!!   fui!   Edmilson --- Em sáb, 19/6/10, Alexandre Valente <alexandre...@gmail.com> escreveu:

[Giovanni Bassi]

Daniel,

Eu uso nos meus projetos.
Eu sempre apresento pros meus clientes. Alguns adotam, outros não.

Projetos de Ruby e Python, quase todos trabalham com TDD. Não dá pra ficar sem numa linguagem dinâmica.

A empresa me parece um pouco desconectada da realidade. Lembrando que TDD não nasceu na literatura, na academia. TDD nasceu nas empresas. Ele foi primeiro praticado, depois documentado.

[]'s

Giovanni Bassi
Arquiteto de software
+55 (11) 8522-5774
Consultoria: www.giovannibassi.com Blog: unplugged.giggio.net

[Giovanni Bassi]

Alexandre,

Discordo em parte. É verdade, não são todos que usam práticas ágeis que usam TDD. Infelizmente.
Já tive clientes que adotaram depois da consultoria, e quando voltei um tempo eles continuavam usando. Mas é difícil manter, é uma prática que exige disciplina. A questão é que os benefícios são tão extensos, que você acaba se disciplinando.

[]'s

Giovanni Bassi
Arquiteto de software
+55 (11) 8522-5774
Consultoria: www.giovannibassi.com Blog: unplugged.giggio.net

[Giovanni Bassi]

Ah, esqueci de dizer algo.
Gerentes não determinam se um time vai usar TDD ou não. Só o próprio time pode decidir isso. Isso NÃO deve vir de cima, sob risco de destruir a auto-gestão de um time. Se quem disse pra esquecer TDD foi algum gerente que disse isso em tom de ordem, a empresa não entende os valores ágeis devidamente.

[]'s

Giovanni Bassi
Arquiteto de software
+55 (11) 8522-5774
Consultoria: www.giovannibassi.com Blog: unplugged.giggio.net

2010/6/18 Daniel Freire <danie...@gmail.com>

[Alexandre Valente]

Sim, em linguagens dinâmicas pode ser que faça mais sentido (não posso falar por experiência, nunca fiz um grande projeto ou trabalhei em um projeto de manutenção de longo prazo usando uma). Mas discordo de vc quanto à visão de que o benefício é claro em C#. Nós já conversamos sobre isto várias vezes, não quero começar de novo! :-). 

Acho que como vc falou, depende de cada time. Se um time é produtivo usando TDD, go for it. Eu só respondi a pergunta, que na prática, em C#, eu realmente ainda não vejo (e tenho dúvida se vou ver um dia) times inteiros usando TDD de maneira consistente.

abs,

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com

www.whitefox.com.br

2010/6/19 Giovanni Bassi <gig...@giggio.net>

[Sidney Lima Filho]

Nossa que saudade do pragmatismo do Valente. rsrsrsrs

Na minha humilde opinião, o TDD é muito interessante quando utilizado parcialmente, concordo com o Alexandre nesse ponto. Inclusive isso foi uma das minhas perguntas no CommLaunch RJ. Como já sabemos que TDD é diferente de testes automatizados, fico com a impressão que TDD é muito eficaz quando a documentação está incompleta, quando os requisitos estão quebrados, quando o cliente não sabe definir o que quer, ele ajuda. Porém não há somente esta forma de expandir a confiabilidade da sua entrega, identificar possiveis impactos, etc.

Acredito que atualmente estamos descobrindo técnicas e metodologias que requerem novos pensamentos e atitudes, afinal numa mesma frase falamos de agilidade, auto-gestão, disciplina e etc. Tampouco podemos atualmente ter capacidade de predizer que uma metodologia é ruim, caso uma equipe não tenha perfil de adoção. Não podemos culpar a METODOLOGIA se a EQUIPE não tem perfil de utilização.

Quando a Toyota implantou sua modelo de gestão de produção, muitas outras ações foram tomadas para que o processo funcionasse. Principalmente com relação aos funcionários. Não será um quadro com post-it que irá mostrar que a equipe usa SCRUM.

Seria leviano dizer que um produto não presta, quando não damos subsidio para a escolha. Isso é com tudo na vida.

A informática é uma ciência bebe, tem menos de 100 anos, se comparada com a Medicina com uns 500 anos, logo estamos no estágio de muito aprendizado. Os cientistas da informação vão descobrir N outros DD's e cada um na sua epoca se mostrará mais eficaz, produtivo, etc...

Isso só nos mostra que a descoberta de novas técnicas sempre tem algo para nos ensinar, talvez pouco, talvez muito, mas sempre tem algo a ensinar. Na minha experiencia com TDD a primeira coisa que aprendi com TDD, como é produtivo de se resguardar, antes de desenvolver, independente de como o faça, no caso do TDD é implementando testes unitários que valide uma especificação, poderiamos fazer de outra forma, como por exemplo, ser feito com script de testes manuais, etc. Óbvio que não estou discutindo o TDD apenas mostrando o como dá para aprender muito e ser mais profissional.



Sidney Lima Filho  ---------------------------------------------------------------------
Vivina Softhouse
(0xx21) 7867-2321
55*10*68934
http://www.vivina.com.br
http://twitter.com/sidneyfilho

2010/6/19 Alexandre Valente <alexandre...@gmail.com>

[Giovanni Bassi]

Oi Sidney,

As vezes tenho a impressão que pragmatismo é desculpa pra não fazer algo que é importante mas você não quer fazer. Sempre que ouço essa palavra, ou que a pronuncio, tomo muito cuidado.

TDD é uma das práticas. BDD é outra, ATDD é outra. Há muitas.

O que posso dizer pra vocês é o seguinte: funciona, mesmo em times inteiros, mesmo em grandes projetos. Poupa tempo, habilita o desenvolvimento. É, na minha opinião, prática fundamental.

[]'s

Giovanni Bassi
Arquiteto de software
+55 (11) 8522-5774
Consultoria: www.giovannibassi.com Blog: unplugged.giggio.net

2010/6/19 Sidney Lima Filho <sidney...@vivina.com.br>

[Alexandre Valente]

Oi Giovanni,

Não tenho dúvidas de que funciona. Ora, até ASP bem feito funciona! :-).

As dúvidas são: é mais produtivo? gera mais qualidade? comparado com o que? aplicável a qualquer time? qualquer cenário? 

Concordo com vc que pragmatismo sem fundamento é tão nocivo quanto desconhecimento. Não acho que seja o caso. Especificamente sobre TDD estamos muito longe de ter consenso - o que é visto pela baixa adesão na prática (o Vinícius vai falar que tem baixa adesão pq o pessoal em geral tem nível baixo, discordo em parte, mesmo em times de alto nível, a adesão não é da maioria :-)).

[Sidney Lima Filho]

Eu sei Giovanni, por isso que falei que tava com saudade do Pragmatismo do Valente, pois sei que ela é o bom pragmatismo.

Quando falo de pragmatismo penso o seguinte, se aplica ao sistema todo? Inclusive àquela parte do código gerada automaticamente? Eu sei que funciona em equipes grandes e projetos grandes. Mas funciona SEMPRE com QUALQUER equipe, funciona SEMPRE em QUALQUER projeto?

Meu ponto de vista é que:  TDD é extremamente válido em várias partes do projeto, mas não em todas. Funciona bem com várias equipes que já participei mas não em todas.

[Vinicius Quaiato]

Eu discordo um pouco das buscas que o Valente faz.

Como vou medir produtividade? Pra mim produtividade está associada a vários fatores, alguns deles:

• clareza do código;
• confiabilidade do código;
• garantia de que o código funciona;
• garantia de que faz o que deve fazer, e ponto;
• facilidade de evolução;
• segurança e tranquilidade na evolução;
• etc

Não se pode medir produtividade sem isso. Não dá pra apenas achar que produtivo é escrever "rápido", e diga-se logo, TDD não te impede de codificar de forma "rápida".

Nos Dojos por exemplo, vemos isso. Pegamos um problema que gerlamente ngm conhece, e entre pessoas que não conhecem TDD, e desenvolvemos de forma segura. É produtivo! 

O problema é que não aceitamos isso como uma prática fundamental.

Antes de um avião decolar, uma série de coisas são feitas: verifica-se os pneus, freios, turbinas, faz-se o abastecimento, etc, etc, etc. São práticas essenciais e fundamentais, que garantem um vôo mais tranquilo e sem problemas.

Talvez fosse mais "produtivo" não fazer nada disso, teriam mais tempo para fazer mais vôos. Mas, o que aconteceria?

Precisamos sim ser pragmaticos! E eu acho que pragmatismo é fazer direito, hehehe.

Att,

Vinicius Quaiato.

[Alexandre Valente]

Oi Vinicus,

Concordo com todos os seus pontos abaixo! :-). E é exatamente esta a questão principal, como medir produtividade? No fundo vai muito com o cenário do cliente e do produto onde se está trabalhando, uma determinada velocidade a uma determinada qualidade é o mínimo que se espera e piorar a velocidade com o objetivo de ser "ter mais garantia e facilidade de evolução" é algo muito subjetivo pra mim. E extremamente difícil de medir.

Na WhiteFox estamos iniciando alguns experimentos para medir, em alguns cenários, o impacto de qualidade (em número de defeitos e tempo gasto em alterações/evoluções) de features desenvolvidas com e sem TDD.... Mas é muito dificil medir isto, já que temos que fechar condições similares de fatures compatíveis para que o estudo seja válido.... Com certeza teremos blog posts sobre isto.

Agora num DOJO é um mundo de ficção. Como alguém falou aqui, na teoria é legal, na prática é outra coisa.... Se o objetivo do DOJO é ensinar TDD, perfeito... se for fazer rápido, vamos medir com e sem em vários casos e vamos comparar! :-) (no nosso ultimo dojo aqui no rio, em C#, foi um caso onde a gente teria atingido o código final em fração do tempo que gastamos com TDD.... Mas é claro que o objetivo ali era treinar TDD, logo valeu muito.... :-)).

Um comentário interessante é o seguinte: eu já vivi exemplos de pessoas que usam TDD e quando tivemos que fazer algo rapidamente pra algum objetivo (uma apresentação p. ex.) e qual a minha surpresa qdo ele não usou TDD.... Aí eu perguntei e ele disse: "ah, assim é mais rápido!" rsrss.... Sem críticas, é o que eu digo: fazer com TDD, mesmo para os mais bem treinados, em geral é mais lento. Claro que em certas situações pode até ser mais rápido e mesmo quando não é pode valer a pena mesmo assim se ganha em algum outro aspecto. Mas na minha humilde visão, na maior parte dos casos do dia-a-dia TDD não é aplicável por ser simplesmente mais lento... E como já falei, não é pq não se usa TDD que "não se faz bem feito", o mundo tá cheio de exemplos que provam o contrário....

Mas chega, senão vamos pra outra thread de 100 emails! :-)

abs,

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com

www.whitefox.com.br

2010/6/19 Vinicius Quaiato <vinicius...@gmail.com>

[Sidney Lima Filho]

Vinicius eu concordo com você, ser pragmático é fazer direito, sem disperdicio de recursos! Quando no enunciado do TDD me fala para não passar para o próximo passo sem antes ter o primeiro funcionando isso coloca meu desenvolvimento na forma linear, quando preciso ter algo exponencial. Então não discordo do tópico do TDD de fazer os testes antes de implementar. Porém é necessário fazer em tudo? É tudo ou nada? ou usa TDD ou não usa?

Eu acredito que uso, mas não faço em todos os casos. Isso é ser pragmático, para que fazer teste de resistencia de uma porta, se só vou usar para abrir e fechar?

Preciso explorar todos os casos de testes? ou alguns básicos já resolve?

Para mim está cada vez mais claro que "test after code" é um caminho mais seguro para desenvolver um código mais estável, limpo e pragmático inclusive.

Porém fica a duvida. Isso funciona com QUALQUER equipe? QUALQUER projeto? Quais testes eu devo fazer? Explorar todas as possibilidades?

[Saulo Carvalho]

[comment OFFTOPIC]

Caros,

 Receio que, falar onde TDD se aplica, aqui no grupo é a mesma coisa que discutir futebol, religião e etc..ou seja não existe um concenso entre as partes. O importante dessa discussão é que mostramos para o Daniel que TDD é sim usado nas empresas, pois se não fosse não seria um assunto que fosse amplamente discutido. Acredito que ponto da thread é : Como eu mostro para uma empresa/equipe, as vantagens/resultados que TDD oferece ?(independente de um time ser ágil ou não).

Fica ai minha sugestão.

Abrações
--
Saulo Carvalho
"Sempre faço o que não consigo fazer para aprender o que não sei." (Pablo Picasso)

[Luiz Henrique C. Correa]

Aqui em Brasília o pessoal da SEA é um bom exemplo de empresa que usa TDD
nos seus projetos.
http://blog.seatecnologia.com.br/

É bem verdade que não usar TDD certamente não significa que vc não utilize
Testes Unitários Automatizados, ou seja, podemos ter testes sem TDD.
Porém hoje, depois de experimentar TDD, penso que não faz mais sentido (pra
mim) escrever testes depois. TDD ajuda na comunicação e no Design da
Aplicação, é uma prática muito valiosa.
Na equipe que eu trabalho estamos começando a adotar TDD, aos poucos, e um
dos motivos que nos fez adotar TDD é justamente porque ninguém da equipe
escreve o teste depois da funcionalidade pronta, sendo assim, estipulamos
que escrever o teste primeiro é o mais indicado.

Abaixo alguns posts que podem ser interessantes para a sua equipe ler:
http://sinnema313.wordpress.com/2010/04/03/the-case-for-test-driven-developm
ent/
http://www.infoq.com/br/articles/relacao-tdd-qualidade
http://rodbv.wordpress.com/2009/03/23/um-mes-de-tdd/

============================================
Luiz Henrique C. Corrêa
MCP, RUP, ITIL
(61) 8143.8430 e (61) 3036.5150
luizh...@gmail.com
============================================

-----Mensagem original-----
De: dotnetar...@googlegroups.com
[mailto:dotnetar...@googlegroups.com] Em nome de Daniel Freire
Enviada em: sexta-feira, 18 de junho de 2010 20:10
Para: dotnetar...@googlegroups.com
Assunto: [dotnetarchitects] Onde existe TDD de verdade no Brasil?

Pessoal,

Abs.,

--

[Sidney Lima Filho]

Sabe como eu convenço as pessoas  que TDD é uma coisa útil? Eu geralmente pergunto a elas o seguinte, vamos supor que um desenvolvedor implementou uma funcionalidade que a principio funciona bem, como você pode garantir, sem fazer Regression Test, que esta funcionalidade nova não irá quebrar outra que já existe?

Normalmente quando apresento os unit tests quebrando, na mesma hora, eles entendem que a pratica do TDD antecipa esta descoberta quando a funcionalidade nova ainda está sendo desenvolvida.

Sidney Lima Filho  ---------------------------------------------------------------------
Vivina Softhouse
(0xx21) 7867-2321
55*10*68934
http://www.vivina.com.br
http://twitter.com/sidneyfilho

2010/6/19 Saulo Carvalho <persona...@gmail.com>

--

[Luiz Henrique C. Correa]

Nas minhas primeiras experiências com TDD não me senti mais produtivo. É uma forma um tanto o quanto diferente de pensar, logo me fez ser mais lento no início (ainda me considero no início, mas as maiores dores já passaram).

Certamente não será utilizando TDD em poucas semanas que iremos sentir uma grande diferença, a diferença vem com a prática constante, com retrospectivas e melhorias na forma de escrever os testes.

 

Pelo pouco que já pratiquei TDD, posso dizer que:

 

É mais produtivo?

No curto prazo não tanto, no médio e longo sim. Com TDD acabamos por escrever um código mais limpo e direto (o necessário para passar no teste), o que acaba por nos tornar mais pragmáticos com o nosso código. Além disso, não vejo porque “5 linhas” de código a mais de testes poderá prejudicar tanto assim na nossa produtividade.

 

Aplicável a qualquer time?

            Deveria ser, acho até que serve como um filtro para os times. Caso um desenvolvedor não consiga se expressar via um código de teste, devemos repensar o papel dele no time, não é mesmo?

 

Aplicável em qualquer cenário?

            Certamente existem cenários (políticos, culturais, tecnológicos e etc..) que TDD não seja viável. Mas acho que seria o caso de repensar o cenário para enfim fazer da “forma correta” e utilizar TDD.

 

O que eu vejo muito por ai, é gente dizendo que TDD não é tão valioso ou que te faz ser menos produtivo. Mas a grande maioria dos que eu ouço falar isso, não tem nenhuma experiência com essa prática (não estou dizendo que é o caso de quem não concorda com TDD aqui na lista, mas foi isso que eu presenciei nas minhas discussões sobre esse tema na minha empresa).

 

 

============================================

Luiz Henrique C. Corrêa

MCP, RUP,  ITIL

( (61) 8143.8430 e (61) 3036.5150
* luizh...@gmail.com

============================================

[Paulo Silveira - Caelum]

Aqui na Caelum usamos o tempo todo. Sinceramente nao sei como ainda se escutam frases como essa... nao consigo mais imaginar em escrever um projeto sem TDD, muito menos sem testes de unidade.

--
Paulo Silveira
Caelum | Ensino e Inovação
www.caelum.com.br
www.arquiteturajava.com.br

2010/6/19 Luiz Henrique C. Correa <luizh...@gmail.com>

[Diego Correa Gonçalves]

TDD: Se você não economiza tempo com ele, está fazendo errado :).
Acontece que algumas empresas não pensam em escalabilidade, não sabem o quanto é economicamente viável, a longo prazo, você estar "protegido" pelos unit tests(principalmente quando chega a hora de um refactor).  Muitas delas querem entregar os projetos muito rápido e de qualquer jeito, e o pior, ainda chegam a cobrar caro de seus consumidores se uma manutenção for muito complicada.
Gosto muito do "design" do código gerado num projeto que se usa TDD e sinceramente espero praticar mais.

---

From: paulo.s...@caelum.com.br
Date: Sat, 19 Jun 2010 16:07:30 -0300
Subject: Re: [dotnetarchitects] Onde existe TDD de verdade no Brasil?
To: dotnetar...@googlegroups.com

---

VEJA TODOS OS SEUS EMAILS DE VÁRIAS CONTAS COM UM SÓ LOGIN. CLIQUE AQUI E VEJA COMO.

[edmilson hora]

"Aplicável a qualquer time?

Deveria ser, acho até que serve como um filtro para os times. Caso um desenvolvedor não consiga se expressar via um código de teste, devemos repensar o papel dele no time, não é mesmo?"

Luiz,  Não concordei com esta parte!   vc disse  que esta no começo da utilização do TDD e vc mesmo disse que foi doloroso,  vc acha  que o  que vc escreveu se aplica a um bom desenvolvedor (Aquele cara que mesmo sem TDD escreve codigos muito legais e resolve  sempre bem os problemas apresentados?)  O que  estou dizendo  é que  não é todo desenvolvedor  que já aplica TDD  no dia a dia,  e se o cara vai começar,  certamente o começo será "dolorozo"  pois  a pratica do teste  antes  exige que mudemos  completamente a maneira como  pensavamos no desenvolvimento.   []´s   Edmilson --- Em sáb, 19/6/10, Luiz Henrique C. Correa <luizh...@gmail.com> escreveu:

De: Luiz Henrique C. Correa <luizh...@gmail.com> Assunto: RES: [dotnetarchitects] Onde existe TDD de verdade no Brasil? Para: dotnetar...@googlegroups.com

[edmilson hora]

@Vinicius,     Desculpe a discordancia, mas o que vc listou  como Produtividade  no meu entendimento tem mais haver com Qualidade (todos os tópicos).   @Valente,  eu estava com saudades  dos  seus  pontos de vista nas discussões!  Não  fique  longe muito tempos vc nos  faz refletir melhor!     Ri muito desta parte:

"eu já vivi exemplos de pessoas que usam TDD e quando tivemos que fazer algo rapidamente pra algum objetivo (uma apresentação p. ex.) e qual a minha surpresa qdo ele não usou TDD.... Aí eu perguntei e ele disse: "ah, assim é mais rápido!" rsrss.... Sem críticas"

--- Em sáb, 19/6/10, Alexandre Valente <alexandre...@gmail.com> escreveu:

De: Alexandre Valente <alexandre...@gmail.com> Assunto: Re: [dotnetarchitects] Onde existe TDD de verdade no Brasil? Para: dotnetar...@googlegroups.com

[juliermecarvalho]

Morro em Vitória ES.

Tenho pouco conhecimento sobre todas as empresas de software daqui.

Mais sei de duas que aplicam e não abrem mão do TDD ou testes
automatizados,
São Qualidata e MidWorks, empresas de médio porte do seguimento.

[Vinicius Quaiato]

@Edmilson

Sim, é exatamente isso que eu disse. Não se dá pra medir produtividade apenas contando quanto tempo a coisa é feita. Produtividade é algo mais profundo do que isso.

@Valente

Pois é, se não me engano fui eu mesmo que fiz esse código aí sem testes.Agora sejamos justos, escrever Random.Next não exige código nenhum, não tem nem por que eu testar isso. Confio no framework. 

Att,

Vinicius Quaiato.

http://viniciusquaiato.com

2010/6/19 edmilson hora <edmils...@yahoo.com.br>

[Vinicius Quaiato]

Esse post e ferramenta do Joshua Kerievsky pode ser útil e interessante:

https://elearning.industriallogic.com/gh/submit?Action=PageAction&album=blog2009&path=blog2009/2010/sessions&devLanguage=Java&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+IndustrialBlogic+(Industrial+Blogic)

Acho que o Alexandre Valente vai gostar das informações que ela pode trazer.

Att,

Vinicius Quaiato

http://viniciusquaiato.com

2010/6/19 Vinicius Quaiato <vinicius...@gmail.com>

[Mauricio Aniche]

Olá Alexandre,

Todos os times na Locaweb usam TDD. Eu ainda não conheci um programador que, após experimentar TDD, tenha voltado atrás. Ao que parece, vc é um deles. Ficaria feliz em tentar entender seus motivos! Vou te mandar um e-mail em particular para discutirmos isso! :)

Sobre aumento de produtividade, qualidade, eu bloguei há algum tempo atrás (http://www.aniche.com.br/2010/04/tdd-realmente-ajuda/) sobre estudos feitos mostrando que, na maioria dos casos, TDD aumenta a produtividade e melhora a qualidade final do código. Alguns desses estudos foram feitos na indústria e outros na academia.

Perguntar se qualquer coisa funciona sempre para qualquer caso e cenário não faz sentido nenhum em engenharia de software. Não existe bala de prata. Vc pode olhar os experimentos feitos e comparar com o seu cenário. Mas, se vc descobriu que no seu cenário TDD é improdutivo (o que, pra mim, é meio improvável), eu tb estou interessado nisso!

Abraços,

Mauricio Aniche

2010/6/19 Alexandre Valente <alexandre...@gmail.com>

[Rodrigo Vidal]

ahahahahah usar o @vQuaiato como exemplo na aplicação de sorteio feita pro CL foi golpe baixo! "Porque é mais rapido".

 

Mas quaiato foi momento de fé né? 

 

Depois posto minha opiniao sobre o assunto.

Rodrigo Vidal
MCPD - MCTS - MCP
www.rodrigovidal.net

[Alexandre Valente]

Oi Mauricio,

A questão não é voltar atrás e sim não usar em todo e qualquer cenário. Como o Vinícius colocou, não faz sentido usar TDD para testar o .Net Framework. Como não faz sentido usar TDD com métodos com poucas linhas ou métodos cujo resultado é previsível e reutilizado em outro contexto. Perceba que isto não é o mesmo que não testar, testes unitários sempre podem ser utilizados, pós-construção, quando julgados necessários.

Então meu ponto é que, saber avaliar o que fazer com e sem TDD não é uma tarefa fácil. Se for usado para tudo sem critério, com certeza teremos perda de tempo e isto vai baixar a produtividade (já que vai ter gente testando o .net framework sem duvida). E pior, muitas pessoas falam "eu uso TDD" e com isto tem uma falsa segurança de que o sistema está com a cobertura e qualidade necessária, quando na verdade não está (afinal, pode haver erros sobre quando a aplicar e pode haver erros até mesmo em um design orientado a testes).

Finalmente, no nosso caso, a maior parte dos erros (talvez mais de 90%?) dos erros dos nossos sistemas em produção são originários na camada de interface. E nesta camada, usar TDD é extremamente complexo pois a explosão combinatória de todos os eventos que podem ser gerados em uma interface somente um pouco complexa já torna a prática inviável em termos de custo.

Então sim, como te falei, nunca tive a chance de ver um time usando TDD por completo em um projeto real de grande porte ou em manutenção de sistemas grandes de mais de 1 ano. Gostaria muito de ver, se vcs tem este cenário com certeza vou pedir pra fazer uma visita aí (eu tenho bons amigos na Locaweb, de repente podemos agendar um chopp). Estou especialmente interessado nestas questões de consistência de uso, de quais os pontos em que se usa e quando não usa, como a questão de TDD aplicado à interface é tratada.

abs,

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com

www.whitefox.com.br

2010/6/20 Mauricio Aniche <maurici...@gmail.com>

[Alexandre Valente]

Bem interesssante.

Como falei, estamos tentando coletar algumas estatísticas internas nossas também. Vamos gerar posts sobre isto assim que evoluirmos nisto.

[Rodrigo Vieira]

Além das pesquisas feitas pelo Scott Ambler, em que ele coleta dados
de milhares de empresas de vários tamanhos (q vc acha no site da
revista Dr Dobbs), vc poderia citar especificamente a IBM, tem um
paper deles sobre isso:

http://portal.acm.org/citation.cfm?id=776892&coll=GUIDE&dl=GUIDE&ret=1

"In a software development group of IBM Retail Store Solutions, we
built a non-trivial software system based on a stable standard
specification using a disciplined, rigorous unit testing and build
approach based on the test- driven development (TDD) practice. Using
this practice, we reduced our defect rate by about 50 percent compared
to a similar system that was built using an ad-hoc unit testing
approach. The project completed on time with minimal development
productivity impact. Additionally, the suite of automated unit test
cases created via TDD is a reusable and extendable asset that will
continue to improve quality over the lifetime of the software system.
The test suite will be the basis for quality checks and will serve as
a quality contract between all members of the team. "

[Diego Caxito]

Sua empresa não vai escrever seu código, logo ela realmente não é capaz de avaliar os benefícios ou não de uma ou outra prática.

O time é capaz e deve decidir.

Utilizo TDD. Montei um Coding Dojo por aqui para ajudar disseminar essa e outras práticas http://dojomoc.wordpress.com

A dúvida sobre TDD que deixa a dificuldade no ar para adoção no início é a grande quebra de paradigma para implementação. Demora para pegar o ritmo, demora bem. A vontade de abandonar é alta no início.

Ele vai estampar na cara seu débito técnico como adoção de patterns, código legível, desacoplado, entre outros.

Quer sair do ostracismo e começar a verificar os benefícios, comece a medir. Utilize métricas para seu código. Comece coletando a quantidade de bugs encontrados, passe para ferramentas de análise de código. Você mede a sua velocidade/time?

Não precisa adotar TDD para isso, comece com a maneira que você faz, depois passe a mudar a forma para melhorar a qualidade. Tome cuidado com as medidas adotadas, não prenda-se a elas, faça com critério e decida junto com seu time. Trabalha em equipe? Quanto tempo demora para arrumar a bagunça no repositório principal? Utiliza automação em quanto de seu processo?

Já estou fugindo do assunto.

Pode iniciar lendo um bom livro, tem o "TDD by Example do Kent Beck", em .Net tem o do Roy Osherove "The Art of Unit Testing".

O Maurício Aniche que nos honra com sua participação é uma excelente fonte, já visitou o blog dele? http://www.aniche.com.br/

Ainda tem o Giggio e outros aqui, como o Phillipe Calçado, sempre expondo boas dicas.

Para realizar algumas métricas em seu código e da sua equipe, de uma olhada inicial na Dissertação do Danilo Sato http://grenoble.ime.usp.br/~gold/orientados/dissertacaoDaniloSato.pdf . Lá você encontra outras boas referências.

Tem que haver no fundo mais empreendedorismo organizacional, próprio e da equipe para adoção de diferentes técnicas. Sem isso não sairemos nunca do lugar.

Comece se perguntando, "o que te impede de usar?". Trabalhe em cima disso.

Abraço a todos.

2010/6/20 Mauricio Aniche <maurici...@gmail.com>

--
Diego Caxito

[Juan Pedro A. Lopes]

Boa! +1

2010/6/21 Diego Caxito <diego...@gmail.com>

--
Kind regards,
Juan Lopes

http://qrcode.juanlopes.net

[André Carlucci]

É normal dizer que uma tecnologia que a gente não usa ninguém usa. É o famoso "se eu não uso não pode ser bom".

Se precisar da mais um exemplo: A Way2 usa TDD.

Concordo que não é nada fácil disseminar essa cultura, talvez seja uma das coisas mais difíceis de se ensinar a um desenvolvedor. Mesmo aqui, vivo pegando código sem testes ou com testes feitos depois da funcionalidade. Delete all, start again, é a vida.

Coding dojo com certeza tem sido a maneira mais efetiva de se ensinar TDD. Mas também ensina só a base, a idéia. Na vida real resolvemos problemas bem diferentes dos que resolvemos nos coding dojos e diferentes problemas requerem diferentes formas de pensar. Tento tapar esse buraco com palestras mostrando exemplos mais do dia a dia e muito pair programming.

Quando alguém experiente aplica pra Way2 e manda o code review sem testes, é praticamente certo que não vai ser chamado pra próxima fase. Acho que todo cara sênior deveria saber isso há muito tempo. Trainees com potencial até passam, mas com certeza se já vier com testes tem muitos pontos na frente.

Desculpe, mas acho irresponsabilidade profissional dar checkin sem testes (quoting Uncle Bob).

A coisa mais triste sobre TDD é que justamente as pessoas que mais precisam da técnica normalmente não a usam.

2010/6/21 Juan Pedro A. Lopes <juanp...@gmail.com>

--
André Carlucci
twitter/andrecarlucci

[Alexandre Valente]

Oi André,

Não sei se vcs tem, mas seria legal ter detalhes de como TDD é aplicado aí, como vcs fazem com as diversas camadas, estatísticas de produtivide e qualidade etc... Como falei, estamos iniciando estas coletas na WhiteFox, acho legal termos experiencias no Brasil documentadas tbm.

Agora só um ponto: ter testes não é a mesma coisa que usar TDD, certo? TDD é uma metodologia de desenvolvimento...   Um erro muito comum é achar que fazer testes unitários é usar TDD, não é.... Vc pode ter código sendo gerado, com uma boa cobertura de casos de teste e ainda assim não usar TDD. Os meus pontos acima sempre se referem à metodologia, não ao uso de testes. Testes obviamente devem ser feitos sempre que necessário.

abs,

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com

www.whitefox.com.br

2010/6/21 André Carlucci <andrec...@gmail.com>

[Saulo Carvalho]

Por isso que gosto do grupo, pois poder compartilhar informações com pessoas de tão alto nível só temos a ganhar. Isso que o Alexandre disse eu não sabia, para mim testes unitários faziam parte da cultura do TDD.  Aqui na empresa usamos testes unitários, como uma forma de aplicar o TDD. Alexandre, se pudesse esclarecer mais um pouco, seria legal. Pois fiquei bastante interessado no assunto. Abrações !!

[Diego Correa Gonçalves]

Na verdade unit-tests são um requerimento para que o TDD aconteça. Escuto muito por ae "TDD isn't about testing, is about Design", então uma cultura de testes por si só não carateriza a aplicação da técnica. O TDD é um tipo de técnica que muda um pouco a forma de pensar, primeiro você testa, esse teste vai falhar(porque você não fez o código a ser testado ainda), depois você escreve o mínimo de código suficiente para que esse teste passe, depois disso você faz um refactor para melhorar a escalabilidade(removendo código duplicado, verificar se está realmente usando o princípio SRP etc....).

Não sou expert no assunto, mas eu pelo menos achei a técnica MUITO eficiente e pretendo aprimorar meu conceito sobre isso.

---

Date: Mon, 21 Jun 2010 13:29:12 -0300
Subject: Re: [dotnetarchitects] Onde existe TDD de verdade no Brasil?
From: persona...@gmail.com
To: dotnetar...@googlegroups.com

--
Você recebeu esta mensagem porque faz parte do grupo .Net Architects hospedado no Google Groups.
Para postar envie uma mensagem para dotnetar...@googlegroups.com
Para sair do grupo envie uma mensagem para dotnetarchitec...@googlegroups.com
Para mais opções visite o grupo em http://groups.google.com/group/dotnetarchitects?hl=pt-br

---

O SEU NAVEGADOR PODE TE PROTEGER DE FRAUDES NA WEB. VEJA DICAS DE INTERNET EXPLORER 8

[Vinicius Quaiato]

É bem por aí mesmo Diego.

TDD não é só sobre testes, é sobre design, entendimento, clareza.

A "promessa" do Kent Beck quando começa a falar de TDD é que você terá "clean code that works". Ou seja, código limpo que funciona.

Estamos também falando sobre segurança e confiança. 

Falamos também sobre saber quando algo terminou.

Não estamos falando de "você terá 100% de cobertura de testes". Ou "você terá 50% mais de produtividade", etc, etc.

Vinicius Quaiato
http://viniciusquaiato.com

My profiles: Twitter
Contact me: vinicius.quaiato

2010/6/21 Diego Correa Gonçalves <frogs...@hotmail.com>

[fabioma...@gmail.com]

Acho que cada time deve utilizar o que lhe faz bem, mas vale a pena
ter outros tipos de visões e testar novos paradigmas. Há empresas mais
conservadoras, e outras mais inovadoras, uma não é pior que a outra,
há prós e contras. Vai da visão da empresa, ou seja, onde quero estar
e o que eu quero ser na data X, é algo de longo prazo, e em TI longo
prazo é um período curto em relação a outras indústrias. Com a visão
definida, você monta o plano de ação. Se TDD faz sentido no plano de
ação, é algo que deve ser experimentado, você pode se dar muito mal e
TDD virar um prática comum, ou se dar bem por não ter escolhido esta
abordagem,em resumo, é uma decisão estratégica, e é esta decisão que
coloca uma empresa na frente da outra. Sucesso de uma empresa, é um
crescimento sustentável.

Eu uso TDD e acho muito bom, tem me ajudado a entregar produtos
melhores. Eu não forço ninguém a utilizá-lo, apenas advogo a favor dos
benefícios que tenho conseguido. De qualquer forma, TDD não garante um
produto de qualidade, ele te ajuda, no mínimo, a garantir que
funcionalidades foram contempladas.

Fabio Margarito

On 19 jun, 12:27, Sidney Lima Filho <sidney.fi...@vivina.com.br>
wrote:

> Sabe como eu convenço as pessoas  que TDD é uma coisa útil? Eu geralmente
> pergunto a elas o seguinte, vamos supor que um desenvolvedor implementou uma
> funcionalidade que a principio funciona bem, como você pode garantir, sem
> fazer Regression Test, que esta funcionalidade nova não irá quebrar outra
> que já existe?
>
> Normalmente quando apresento os unit tests quebrando, na mesma hora, eles
> entendem que a pratica do TDD antecipa esta descoberta quando a
> funcionalidade nova ainda está sendo desenvolvida.
>
> Sidney Lima Filho
>  ---------------------------------------------------------------------
> Vivina Softhouse
> (0xx21) 7867-2321
> 55*10*68934http://www.vivina.com.brhttp://twitter.com/sidneyfilho
>

> 2010/6/19 Saulo Carvalho <personal.sa...@gmail.com>
>
>
>
> > *[comment OFFTOPIC]*
> > *
> > *

> > Caros,
> >  Receio que, falar onde TDD se aplica, aqui no grupo é a mesma coisa que
> > discutir futebol, religião e etc..ou seja não existe um concenso entre as
> > partes. O importante dessa discussão é que mostramos para o Daniel que TDD é
> > sim usado nas empresas, pois se não fosse não seria um assunto que fosse
> > amplamente discutido. Acredito que ponto da thread é : Como eu mostro para
> > uma empresa/equipe, as vantagens/resultados que TDD oferece ?(independente
> > de um time ser ágil ou não).
>
> > Fica ai minha sugestão.
> > Abrações
> > --
> > Saulo Carvalho
> > "Sempre faço o que não consigo fazer para aprender o que não sei." (Pablo
> > Picasso)
>
> > --
> > Você recebeu esta mensagem porque faz parte do grupo .Net Architects
> > hospedado no Google Groups.
> > Para postar envie uma mensagem para dotnetar...@googlegroups.com
> > Para sair do grupo envie uma mensagem para

> > dotnetarchitec...@googlegroups.com<dotnetarchitects%2Bunsubscrib­e...@googlegroups.com>

> > Para mais opções visite o grupo em

> >http://groups.google.com/group/dotnetarchitects?hl=pt-br- Ocultar texto das mensagens anteriores -
>
> - Mostrar texto das mensagens anteriores -

[Alexandre Valente]

Oi Saulo,

Exato. E esta é uma dúvida muita frequente, muita gente acha que se está usando testes unitários, está usando TDD.... Uma coisa não tem nada a ver com a outra. Então, só para sumarizar:

- Desenvolvimento normal: o desenvolvedor entende o problema, modela o domínio, projeta o que quer fazer e começa a construir. Cada artefato construído é feito para atingir um objetivo de domínio específico. Os testes unitários são construídos sempre que necessário após ou durante a construção do item. Normalmente os testes são mais utilizados em regras de negócio ou então quase como testes de integração, executando vários componentes do sistema em caminhos típicos.

- Desenvolvimento com TDD: o desenvolvedor entende o problema, modela o domínio, identifica o que é esperado do determinado artefato, faz o teste para aquilo, o teste falha, ele faz o código até o teste passar e assim iterativamente até funcionar tudo. O teste passa a ser o design e todo o desenvolvimento fica orientado a fazer o teste primeiro, e não a construir o artefato inicialmente. Obviamente que com TDD os testes sempre são produzidos, normalmente com grande cobertura. Em tese isto deveria ser aplicado a todas as camadas da aplicação.

Então, reforçando, é claro que usamos testes quando necessário. Porém eu não acho que TDD seja o único ou melhor caminho para se desenvolver, acho que é uma metodologia como muitas outras, aplicável bem a alguns casos mas que em outros não; e que a adequação ou uso dela tem que ser pesado caso a caso. Igual a TDD tem várias outras (BDD p. ex.) que pregam gerar os mesmos benefícios.

abs,

Alexandre Valente

MCSE+I, MCSD, MDCBA, ITIL, CSM

agvalente.wordpress.com

www.whitefox.com.br

2010/6/21 Saulo Carvalho <persona...@gmail.com>

--

[Diego Correa Gonçalves]

Realmente a questão do TDD x Unit-Testing é uma coisa que podem gerar alguma confusão no começo, aqui, tratamos testes e TDD da seguinte maneira:


Testes de integração (Selenium exemplo): Encontrar Bugs(coisas que funcionam de maneira inesperada)
Unit-Tests: Ajudar um possível refactor e encontrar breaking-changes (coisas que funcionavam e param de funcionar após uma determinada mucança)
Desenvolver componentes de software suscetíveis a mudanças e fracamente acoplados : TDD, automaticamente você está também "protegido" pelos seus unit-tests para futuras mudanças.

Outra coisa que chegamos a conclusão é que, por exemplo, é desnecessário testar "controladores" e outros componentes do frameworks, já que estes já possuem seus unit tests(é só baixar o source code e ver).
Algumas dicas bem simples pra quem está começando são:
Teste somente uma coisa por vez: Verifique nos seus métodos de unit-test se voce está fazendo mais de um assertion é uma boa dica.
Se seus unit tests precisam ser "rodados" em uma sequencia específica ou dependem um do outro para executar, eles estão errados, não são mais "testes de unidade" evitando isso voce previne que seu trabalho seja perdido e que chegue num ponto que você não consiga manter seus testes.

---

From: alexandre...@gmail.com
Date: Mon, 21 Jun 2010 20:06:04 -0300

Subject: Re: [dotnetarchitects] Onde existe TDD de verdade no Brasil?

To: dotnetar...@googlegroups.com

---

GUARDE GRATUITAMENTE SEUS ARQUIVOS NA WEB. CLIQUE AQUI E VEJA UM PASSO A PASSO.

[Giovanni Bassi]

Não só testes unitários. Podem ser integrados também. E agora se fala também de ATDD, Acceptance Test Driven Development.

[]'s

Giovanni Bassi
Arquiteto de software
+55 (11) 8522-5774
Consultoria: www.giovannibassi.com Blog: unplugged.giggio.net

2010/6/21 Diego Correa Gonçalves <frogs...@hotmail.com>

Na verdade unit-tests são um requerimento para que o TDD aconteça. Escuto muito por ae "TDD isn't about testing, is about Design", então uma cultura de testes por si só não carateriza a aplicação da técnica. O TDD é um tipo de técnica que muda um pouco a forma de pensar, primeiro você testa, esse teste vai falhar(porque você não fez o código a ser testado ainda), depois você escreve o mínimo de código suficiente para que esse teste passe, depois disso você faz um refactor para melhorar a escalabilidade(removendo código duplicado, verificar se está realmente usando o princípio SRP etc....).

[Humberto Marchezi]

Como Uncle Bob dizia, é melhor ter um software TDD com arquitetura ruim do que ter um software com ótima arquitetura mas em TDD. Pois o detalhe é que o primeiro pode evoluir.

t+

2010/6/22 Giovanni Bassi <gig...@giggio.net>

--
Humberto C Marchezi
---------------------------------------------------------