TDD - Test Driven Design

[fabioma...@gmail.com]

Vamos agitar um pouco este grupo!

Para quem já está utilizando o TDD:

Como foi o processo de adoção?
Quais as dificuldades vocês tiveram?
Quais ferramentas vocês utilizam para melhorar a produtividade(IDEs,
Frameworks Mocks) e como são utilizadas dentro do processo?
Vocês tiveram benefícios a curto ou longo prazo?
Quais foram as lições aprendidas?
Vocês possuem alguma métrica sobre o ROI(Return of investiment), após
aplicação da técnica?
Para quem ainda não usa, como vocês podem convencê-los a usar?


Abraços
Fábio

[Giovanni Bassi]

Eu não uso e até o momento não vi o valor a ponto de recomendar. Sinto que essa idéia de "sair codificando" depois de fazer o teste dá uma grande margem a uma arquitetura pobre. Ainda prefiro montar a arquitetura, definir as entidades, e, para cada método criado, criar também um teste. O desenvolvimento não dirigido (driven) pelos testes, mas os testes continuam com função muito importante.

[]s

Giovanni Bassi

2008/11/14 fabioma...@gmail.com <fabioma...@gmail.com>

[João Carlos Clementoni Silva]

Como foi o processo de adoção?

 Com desconfiança pois não se acreditava nesta prática. Com o o tempo e o aparecimento dos benefícios está 100% aceito.

Quais as dificuldades vocês tiveram?

Entender o funcionamento dos mock objects e prazos apertados impedindo a realização da prática em alguns casos.

Quais ferramentas vocês utilizam para melhorar a produtividade(IDEs,
Frameworks Mocks) e como são utilizadas dentro do processo?

TestDriven.NET para integração com Visual Studio, Nunit para rodar os testes, Nant para rodar automatizado, CruiseControl.NET para rodar a cada checkin de código, Rhino Mocks para "mockar" objetos.

Vocês tiveram benefícios a curto ou longo prazo?

Adotamos recentemente então não dá para falar a longo prazo, mas a curto prazo vários benefícios como redução de retrabalho nas tarefas, aumento da qualidade do software e o melhor aumento da confiança da equipe em entregar o software.

Quais foram as lições aprendidas?

Impossível 100% cobertura e a arquitetura tem que colaborar.

Vocês possuem alguma métrica sobre o ROI(Return of investiment), após
aplicação da técnica?

Não, apenas feeling. 

Para quem ainda não usa, como vocês podem convencê-los a usar?

Para quem não conhece, procure saber. Para quem conhece e desconfia, experimente usar em um projeto real. 

[Leandro Daniel]

Gostaria de acrescentar mais alguns questionamentos para discussão
entre os colegas:

1 - Nos cases vivenciados, houve coleta de métricas antes e após a
aplicação de TDD? Se sim, quais os resultados?
2 - Mesmo havendo apenas a percepção de ganho, seria possível pontuar
o percentual de variação de esforço em um projeto com e sem TDD?
3 - Quais os desdobramentos para equipes compostas por desenvolvedores
e analistas de qualidade (testers)?

Percebam que, com os questionamentos acima, estou mais preocupado com
a relação de esforço/skill e custos efetivos para o projeto.

Abraços,

Leandro Daniel

On Nov 14, 8:52 am, "fabiomargar...@gmail.com"

[Giovanni Bassi]

Aproveito para apresentar aos colegas um estudo feito pela NRC Institute for Information Technology, comparando oTDD com a abordagem convencional:
http://iit-iti.nrc-cnrc.gc.ca/publications/nrc-47445_e.html
Para os sem tempo ou sem paciência, leiam só o abstract. Ele diz o seguinte:

• A abordagem "teste antes" ou "teste depois" não fez diferença;
• Os desenvolvedores que escreveram mais testes tiveram melhor qualidade;
• Desenvolvedores de TDD escrevem mais testes;
• TDD gerou melhor qualidade.
  

Um parágrafo bem legal na conclusão:

"Test-First programmers did not achieve better quality on
average, although they achieved more consistent quality
results. We attribute the latter observation to the influence
of skill on quality, which Test-First tended to dampen.
Writing more tests improved the minimum quality achievable
and decreased the variation, but this effect does not
appear to be specific to Test-First."

Interessante, não é? Na verdade, a conclusão é que não faz a menor diferença se você escreve testes antes ou depois, desde que o faça. Para quem gosta do assunto e tem paciência de ler as 13 páginas do documento, acho bem legal.

Aliás, alguém podia falar de TDD na quarta reunião do grupo, o que vocês acham? Tem que ser alguém que usa de verdade no dia a dia, e não só estudou, para trazer as vantagens e desvantagens. O calendário ficaria assim:
2ª Reunião: Antonio Zeguni: Metodologia Ágil
3ª Reunião: Giovanni Bassi: DDD
4ª Reunião: TDD (proposta): ??

Fica a sugestão.

[]s

Giovanni Bassi

2008/11/15 Leandro Daniel <lda...@emphasys.com.br>

[Leandro Daniel]

Giovanni, acho muito boa a proposta de TDD como tema para a 4ª
reunião, e começo a acreditar que reuniões quinzenais podem tornar-se
uma realidade para este grupo. Acho válido mantermos o link entre
estes temas sempre que possível, pois muitos assuntos são correlatos.

Abraços,

Leandro Daniel

On Nov 15, 12:21 pm, "Giovanni Bassi" <gig...@giggio.net> wrote:
> Aproveito para apresentar aos colegas um estudo feito pela NRC Institute for
> Information Technology, comparando oTDD com a abordagem convencional:http://iit-iti.nrc-cnrc.gc.ca/publications/nrc-47445_e.html
> Para os sem tempo ou sem paciência, leiam só o abstract. Ele diz o seguinte:
>

>    - A abordagem "teste antes" ou "teste depois" não fez diferença;
>    - Os desenvolvedores que escreveram mais testes tiveram melhor qualidade;
>    - Desenvolvedores de TDD escrevem mais testes;
>    - TDD gerou melhor qualidade.

>
> Um parágrafo bem legal na conclusão:
>
> > "Test-First programmers did not achieve better quality on
> > average, although they achieved more consistent quality
> > results. We attribute the latter observation to the influence
> > of skill on quality, which Test-First tended to dampen.
> > Writing more tests improved the minimum quality achievable
> > and decreased the variation, but this effect does not
> > appear to be specific to Test-First."
>
> Interessante, não é? Na verdade, a conclusão é que não faz a menor diferença
> se você escreve testes antes ou depois, desde que o faça. Para quem gosta do
> assunto e tem paciência de ler as 13 páginas do documento, acho bem legal.
>
> Aliás, alguém podia falar de TDD na quarta reunião do grupo, o que vocês
> acham? Tem que ser alguém que usa de verdade no dia a dia, e não só estudou,
> para trazer as vantagens e desvantagens. O calendário ficaria assim:
> 2ª Reunião: Antonio Zeguni: Metodologia Ágil
> 3ª Reunião: Giovanni Bassi: DDD
> 4ª Reunião: TDD (proposta): ??
>
> Fica a sugestão.
>
> []s
>
> Giovanni Bassi
>

> 2008/11/15 Leandro Daniel <ldan...@emphasys.com.br>

> > > Fábio- Hide quoted text -
>
> - Show quoted text -

[Giovanni Bassi]

Olá Leandro,

Na primeira reunião o grupo achou que estava bom nos reunirmos mensalmente, mas podemos discutir isso na próxima reunião.

[]s

Giovanni Bassi

2008/11/15 Leandro Daniel <lda...@emphasys.com.br>

[Rafael Izidoro]

Ainda não apliquei TDD na prática, tenho apenas estudado e vejo muitas
pessoas falarem das vantagens de testar primeiro, como por exemplo
codificar somente o necessário etc.
Giovanni, por que você acha que esta técnica pode comprometer a
arquitetura?

On Nov 15, 12:58 pm, "Giovanni Bassi" <gig...@giggio.net> wrote:
> Olá Leandro,
>
> Na primeira reunião o grupo achou que estava bom nos reunirmos mensalmente,
> mas podemos discutir isso na próxima reunião.
>
> []s
>
> Giovanni Bassi
>

> 2008/11/15 Leandro Daniel <ldan...@emphasys.com.br>

[Giovanni Bassi]

Rafael,

É complexo.
Falando do ponto de vista de quem conhece as práticas de TDD apenas pelos seus princípios, sinto que o desenvolvimento pode acabar sendo feito de maneira não planejada. Já que o ponto de vista do codificador do teste é o ponto de vista do cliente da API que será depois criada, esta API pode acabar sendo criada com uma simplificação excessiva, além de poder ficar muito fragmentada.
Imagine que um desenvolvedor precisa no seu teste de uma entidade "cliente". Ele cria o teste, depois cria a entidade. Em outro momento, outro desenvolvedor também precisa de uma entidade cliente, mas sob outro contexto. Ele cria esta nova entidade, mesmo que ambas representem a mesma entidade do mundo real, o cliente, e isso é perfeitamente ok. No entanto, toda a discussão a respeito de como essas duas entidades interagem pode ter sido perdida. Não discutiu-se se deve-se criar um contexto único e unificar as entidades, ou separar os contextos, e se fossem separados, se se comunicariam, e como. Toda essa discussão é relevante, e, acredito, deve ser feita antes de escrever o código de teste. E se essa discussão for feita, e diagramas e códigos forem gerados, ainda podemos considerar TDD?

Um abraço,

Giovanni Bassi

2008/11/15 Rafael Izidoro <raf...@gmail.com>

[tucaz]

Giovanni,

esses últimos pontos que você colocou são realmente pertinentes e você
próprio deu a resposta. Como TDD é feito utilizando como ponto de
partida o ponto de vista do cliente da API pelo codificador os
resultados tendem a ser simples. Esse é um dos maiores pontos
positivos do método (além é claro de ter todos testes preparados).
APIs devem ser simples o suficiente para darem conta do recado. Pra
que complicar se podemos simplificar?

Com relação a questão da unificação da API de Cliente a resposta é
essa mesmo: comunicação. O fato de escrever testes antes de codificar
de forma alguma elimina a necessidade de comunicação e planejamento. A
idéia toda de metodologias ágeis, modelagem ágil (Scott Ambler) e TDD
é eliminar desperdício fazendo somente o necessário.

O ponto importante disso tudo é encontrar o equilibrio entre as
práticas. O fato de planejar, comunicar e modelar antes de escrever os
testes de forma alguma deixa de ser TDD.

Antonio Carlos Zegunis Filho
http://blog.tucaz.net

> Falando do ponto de vista de quem conhece as práticas de TDD apenas pelos
> seus princípios, sinto que o desenvolvimento pode acabar sendo feito de
> maneira não planejada. Já que o ponto de vista do codificador do teste é o
> ponto de vista do cliente da API que será depois criada, esta API pode
> acabar sendo criada com uma simplificação excessiva, além de poder ficar
> muito fragmentada.
> Imagine que um desenvolvedor precisa no seu teste de uma entidade "cliente".
> Ele cria o teste, depois cria a entidade. Em outro momento, outro
> desenvolvedor também precisa de uma entidade cliente, mas sob outro
> contexto. Ele cria esta nova entidade, mesmo que ambas representem a mesma
> entidade do mundo real, o cliente, e isso é perfeitamente ok. No entanto,
> toda a discussão a respeito de como essas duas entidades interagem pode ter
> sido perdida. Não discutiu-se se deve-se criar um contexto único e unificar
> as entidades, ou separar os contextos, e se fossem separados, se se
> comunicariam, e como. Toda essa discussão é relevante, e, acredito, deve ser
> feita antes de escrever o código de teste. E se essa discussão for feita, e
> diagramas e códigos forem gerados, ainda podemos considerar TDD?
>
> Um abraço,
>
> Giovanni Bassi
>

> 2008/11/15 Rafael Izidoro <raf4...@gmail.com>

[Giovanni Bassi]

Antonio,

Achei algo estranho aí. Fui buscar o processo do TDD, segundo a wikipedia (http://en.wikipedia.org/wiki/Test-driven_development#Test-Driven_Development_Cycle):

1. Add a test
2. Run all tests and see if the new one fails
3. Write some code
4. Run the automated tests and see them succeed
5. Refactor code
6. Repeat

Pelo que está aí, não há modelagem, se há, é só depois (no passo de refatoração). Há a criação do teste, do código, e depois a refatoração. Se antes criarmos o modelo, e depois criarmos o teste, o Desenvolvimento não é Dirigido pelo Teste (TDD), mas pelo Modelo (Model Driven Development) ou pelo domínio (Domain Driven Development). Por isso meu questionamento: ainda seria TDD?

Quanto à simplificação, acho que o principio do KISS pode ser aplicado tando em TDD quanto em outras práticas.

Além disso tudo, se o TDD realmente não leva à uma qualidade maior por si só, mas indiretamente conforme o estudo que falei antes (não sei se a outros, se hover, gostaria de ver), mas quem o faz é a criação dos testes, independentemente de como o desenvolvimento é dirigido, meu questionamento sobre o TDD se reforça. Até porque já vi outras técnicas/idéias serem apresentadas como balas de prata, solução para todos os problemas, que receberam grandes investimentos, e hoje estão morrendo e sendo até demonizadas por boa parte do mercado, como o desenvolvimento em cascata, e o CMMi.
Nada contra o TDD, mas gostaria realmente de ver argumentos mais concretos, por isso sugeri que alguém falasse dele em uma das nossas reuniões. Como falei no começo, ainda não me convenci. Vi a sugestão do João Carlos Clementoni Silva de rodar um projeto com TDD, mas isso depende muito do cliente, mas vou tentar, vamos ver. Antes, no entanto, queria ver esses depoimentos, se possível, de forma não apaixonada e baseada em realizações reais, que provassem que se o TDD não estivesse presente o sucesso não viria ou não seria o mesmo. Projetos custam caro, e aplicar uma técnica nova deve ser feito quando ela tem esse tipo de comprovação.
Outra coisa que me incomoda um pouco é que às vezes a comunidade, de vez enquanto até as empresas, adotam idéias novas e começam a propagá-las como se isso tornasse a pessoa/empresa mais competente, quando o que está sendo feito é aproveitar-se de mais uma buzz word e do hype que vem com ela. Mais uma vez cito o CMMi que diversas empresas estão abandonando, ou por completo, ou cancelaram o projeto de expandir o nível de maturidade ou a amplitude do programa. Houve um momento no mercado em que as práticas do CMMi eram colocadas como bala de prata. Concorrências só eram entregues para empresas certificadas a partir de um certo nível. O resto do mercado era isso mesmo: o resto. De repente notou-se o custo que o CMMi trouxe, comparou-se com o valor que ele apresenta, e deu no que deu. Qual a prova de que TDD não segue o mesmo caminho e de que não estamos cometendo o mesmo erro de novo?
Coloco as questões realmente porque elas mesmas estão na minha mente neste momento e me incomodam. Adoraria ver respostas positivas à estas perguntas, porque realmente a técnica parece interessante, mas até o momento tenho visto muito oba oba a respeito da prática, mas poucos números. E eu gosto de números.

[]s

Giovanni Bassi

2008/11/16 tucaz <tuc...@gmail.com>

[tucaz]

Opa Givanni! Vamos la...

TDD é apenas mais uma prática de engenharia de software que objetiva
aumentar a qualidade tanto do produto final (em questão de bugs)
quanto do modelo (código) gerado. Essa etapa de modelagem não está ai,
porque ela esta contida num guarda-chuva maior (processo/framework/
metodologia de desenvolvimento) de software assim como TDD também
está. Modelagem não é um passo do TDD, mas ambos são etapas do ciclo
de vida de desenvolvimento de software. Seria mais ou menos assim:

1 - Levantar requisitos (histórias?)
2 - Modelar em grupo
3 - Desenvolver (usando TDD)

A primeira etapa do ciclo de TDD (add a test) diz que temos que
escrever um teste, mas esse teste deve ser útil. Como fazemos isso?
Modelando e fazendo levantamentos. Sem que os critérios de aceite de
uma história estejam definidos é improvável que seus testes sejam
úteis. Sendo assim, precisamos levantar os critérios de aceite ou
cenários de teste e como fazemos isso? Modelando e levantando
novamente. Percebe onde quero chegar? A idéia toda de testar não é o
teste em si (também é), mas o processo criativo que a atividade de
testar desencadeia. Quando um desenvolvedor precisar escrever testes
antes de escrever o código de uma API ele deve pensar a respeito dela
e neste momento, sozinho ou não, ele está modelando e planejando o que
irá construir. Nesse momento de início de testes é onde ele irá
estudar o que vai construir, levantar as possíveis falhas e tirar
dúvidas. TDD é mais sobre colocar o desenvolvedor pra pensar do que
efetivamente escrever testes. Os testes são um bonus.

Independente da metodologia utilizada um projeto vai ter sucesso ou
não de acordo com a equipe que estiver executando-o. Então acho pouco
provável que você encontre algum estudo de caso dizendo "Sem TDD não
teriamos conseguido". Uma equipe boa fazendo um projeto com modelo
waterfall puro vai alcançar o sucesso naturalmente. Na minha opinião,
práticas podem ajudar, mas não são o diferencial.

Att.,

Antonio Carlos Zegunis Filho
http://blog.tucaz.net

On 16 nov, 22:09, "Giovanni Bassi" <gig...@giggio.net> wrote:
> Antonio,
>

> Achei algo estranho aí. Fui buscar o processo do TDD, segundo a wikipedia (http://en.wikipedia.org/wiki/Test-driven_development#Test-Driven_Deve...
> ):
>
>    1. Add a test
>    2. Run all tests and see if the new one fails
>    3. Write some code
>    4. Run the automated tests and see them succeed
>    5. Refactor code
>    6. Repeat

>
> Pelo que está aí, não há modelagem, se há, é só depois (no passo de
> refatoração). Há a criação do teste, do código, e depois a refatoração. Se
> antes criarmos o modelo, e depois criarmos o teste, o Desenvolvimento não é

> Dirigido pelo *Teste* (*TDD*), mas pelo *Modelo* (*Model* Driven
> Development) ou pelo *domínio* (*Domain* Driven Development). Por isso meu

> 2008/11/16 tucaz <tuca...@gmail.com>

> ...
>
> mais »

[Giovanni Bassi]

Antonio, estou entendendo onde você quer chegar. Só que o nome da técnica leva à uma compreensão errada, afinal, o projeto não é TDD (dirigido por testes), só uma etapa, a mais simples de todas, na verdade, seria TDD. O resto o projeto mesmo, seria, por exemplo, DDD (dirigido pelo domínio).
E sinceramente, entendo que codificar é muito mais simples do que entender o cliente e modelar. Talvez por isso o resultado daquele estudo que apresentei... Eu entendia que o TDD tinha uma pretensão maior. Enfim, vivendo e aprendendo.
:)

[]s

Giovanni Bassi

2008/11/16 tucaz <tuc...@gmail.com>

[tucaz]

Não sou o maior conhecedor da técnica, mas sei da forte relação com XP
que também se apoia em user stories para determinar o ritmo e caminho
do desenvolvimento. Acho que concordo com você no que diz respeito ao
nome. Faz parecer que nenhuma outra técnica de modelagem pode/deve ser
utilizada, mas só testes.

No entanto, aplicar TDD não é coisa mais fácil do mundo e por conta da
dificuldade traz ganhos incrivéis para os integrantes do time. Por
exemplo, se você tiver alguém que não conhece interfaces e patterns
para tornar seu código menos acoplado peça para ele aplicar TDD. No
começo vai sair tudo uma caca e nenhum teste vai ser escrito, mas com
a prática essa pessoa irá desenvolver habilidades fantásticas em
design by contract e código altamente reutilizável e desacoplado. Se o
código não for desse jeito, é impossível testar.

Soçarba!

Att.,
Antonio Carlos Zegunis Filho
http://blog.tucaz.net

On 16 nov, 22:54, "Giovanni Bassi" <gig...@giggio.net> wrote:
> Antonio, estou entendendo onde você quer chegar. Só que o nome da técnica
> leva à uma compreensão errada, afinal, o projeto não é TDD (dirigido por
> testes), só uma etapa, a mais simples de todas, na verdade, seria TDD. O
> resto o projeto mesmo, seria, por exemplo, DDD (dirigido pelo domínio).
> E sinceramente, entendo que codificar é muito mais simples do que entender o
> cliente e modelar. Talvez por isso o resultado daquele estudo que
> apresentei... Eu entendia que o TDD tinha uma pretensão maior. Enfim,
> vivendo e aprendendo.
> :)
>
> []s
>
> Giovanni Bassi
>

> 2008/11/16 tucaz <tuca...@gmail.com>

> ...
>
> mais »

[Fabio Margarito]

A discussão sobre a Técnica de TDD com algumas citações sobre o DDD, me trazem algumas idéias e guias que poderiam ser criados pelo grupo.

 

Por exemplo, para quem houve falar de TDD ou DDD, acredita a princípio que são duas formas distintas para se criar software, sendo que na realidade no meu entendimento e de acordo com o Tucaz “Guarda Chuva Maior”, são complementares, explico: Vou trazer um pouco mais para a ceara do meu conhecimento, o RUP(Rational Unified Process). Se olharmos para o famigerado "gráfico das baleias", vejo que o DDD poderia se encaixar muito bem na fase de Inception(Inicial),Elaboration(Elaboração) e o TDD poderia ter início na Elaboration, ou na própria Construction(Implementação), estou me atendo apenas as fases e poderia explorar mais o assunto mas acho que daria um TCC J. Poderíamos atuar na construção de alguns guias, ou workarounds, mostrando onde utilizar as técnicas, ou seja, realizar alguns possíveis mapeamentos dentro dos processos de software disponíveis se possível.  

 

 

 

Entenderam onde eu gostaria de chegar? Não seria um trabalho fácil, exige estudo e aplicações práticas e seria feito bem mais adiante!

 

Seria muito interessante se encontrássemos pessoas com cases aplicando TDD ou qualquer outra técnica que seja de interesse do grupo, mas que estes fossem cases reais, mesmo que sem sucesso e que nos trouxessem valores tangíveis. Assim como o Giovanni, acho interessante os números, pois uma escolha errada pode trazer problemas irreversíveis e perda de credibilidade.

 

Acho que nosso grupo poderia contribuir muito e trazer a realidade dos fatos, pois estou farto de ouvir alguns profissionais, ou mesmo em palestras onde a demagogia impera, ou seja, sempre ocorre o “caminho feliz” onde todo projeto é um sucesso, e na realidade a estória não é bem assim, pois muita coisa é omitida ou pequenos feitos supervalorizados. Estou gostando das discussões iniciais do grupo e o senso crítico dos participantes, espero que outras pessoas se engajem e contribuam com suas experiências.

 

 

 

Abraços

Fábio

 

 

 

-----Mensagem original-----
De: dotnetar...@googlegroups.com [mailto:dotnetar...@googlegroups.com] Em nome de tucaz
Enviada em: domingo, 16 de novembro de 2008 23:13
Para: .Net Architects
Assunto: [dotnetarchitects] Re: TDD - Test Driven Design

[Rafael Izidoro]

Na minha leitura, vi que devido a este fato que o Giovanni relatou, de
achar que o TDD é somente para teste(como o nome sugere), surgiu o BDD
http://en.wikipedia.org/wiki/Behavior_Driven_Development , que é uma
'evolução' ao TDD. Este assunto é mais abordado na comunidade Ruby, no
mundo .NET vi pouca coisa sobre o assunto.

On 17 nov, 00:30, "Fabio Margarito" <fabiomargar...@gmail.com> wrote:
> A discussão sobre a Técnica de TDD com algumas citações sobre o DDD, me
> trazem algumas idéias e guias que poderiam ser criados pelo grupo.
>
> Por exemplo, para quem houve falar de TDD ou DDD, acredita a princípio que
> são duas formas distintas para se criar software, sendo que na realidade no
> meu entendimento e de acordo com o Tucaz “Guarda Chuva Maior”, são
> complementares, explico: Vou trazer um pouco mais para a ceara do meu
> conhecimento, o RUP(Rational

> <http://carlosmaju.blogspot.com/2006/11/introduo-ao-rup.html>  Unified

> Process). Se olharmos para o famigerado "gráfico das baleias", vejo que o
> DDD poderia se encaixar muito bem na fase de
> Inception(Inicial),Elaboration(Elaboração) e o TDD poderia ter início na
> Elaboration, ou na própria Construction(Implementação), estou me atendo
> apenas as fases e poderia explorar mais o assunto mas acho que daria um TCC
> J. Poderíamos atuar na construção de alguns guias, ou workarounds, mostrando
> onde utilizar as técnicas, ou seja, realizar alguns possíveis mapeamentos
> dentro dos processos de software disponíveis se possível.  
>

> ...
>
> mais »
>
>  image001.png
> 45KExibirDownload

[Victor Cavalcante]

Olá Pessoal,

Estou adorando a movimento do grupo, e percebi que vocês adoram mandar e-mail no final de semana, me assustei quando vi a quantidade de e-mail do grupo (um susto bom).
Vamos ao que interessa, em relação ao TDD eu concordo com o que o Tuca falou, que ele está em baixo de um grande guarda-chuva, mas também concordo com o Giovanni em relação ao nome do TDD que é incoerente de acordo com a prática.
Isso pode ser visto na imagem abaixo que ilustra o AMDD (Agile Model Driven Development).









Abraços,

Victor Cavalcante

2008/11/17 Rafael Izidoro <raf...@gmail.com>

[Rafael Izidoro]

Existe um framework BDD em ruby chamado RSpec. Andei fazendo umas
pesquisas e vi que criaram algo parecido para .NET, chamado NSpec
http://nspec.tigris.org/ . Um video interessante sobre o assunto pode
ser visto no RailsEnvy http://www.railsenvy.com/2007/10/4/how-i-learned-to-love-testing-presentation
.

On 17 nov, 10:11, "Victor Cavalcante" <vic...@cavalcante.net> wrote:
> Olá Pessoal,
>
> Estou adorando a movimento do grupo, e percebi que vocês adoram mandar
> e-mail no final de semana, me assustei quando vi a quantidade de e-mail do
> grupo (um susto bom).
> Vamos ao que interessa, em relação ao TDD eu concordo com o que o Tuca
> falou, que ele está em baixo de um grande guarda-chuva, mas também concordo
> com o Giovanni em relação ao nome do TDD que é incoerente de acordo com a
> prática.
> Isso pode ser visto na imagem abaixo que ilustra o AMDD (Agile Model Driven

> Development). <http://www.agilemodeling.com/>
>
> [image:http://www.cavalcante.net/imagens/AMDD.gif]
>
> Abraços,
>
> Victor Cavalcante
>
> 2008/11/17 Rafael Izidoro <raf4...@gmail.com>

>
>
>
> > Na minha leitura, vi que devido a este fato que o Giovanni relatou, de
> > achar que o TDD é somente para teste(como o nome sugere), surgiu o BDD

> >http://en.wikipedia.org/wiki/Behavior_Driven_Development, que é uma

> ...
>
> mais »

[João Carlos Clementoni Silva]

Olá,

Na equipe que trabalho utilizamos o TDD na fase desenvolvimento. Não temos uma fase formal de modelagem. Modelamos quando é necessário pensar sobre o problema. Como utilizamos os padrões envolvidos no DDD, o desenvolvedor não tem muito o que inventar na arquitetura. 

Pra gente o TDD tem ajudado a fazer apenas o necessário para o código passar no teste. O resultado que tem acontecido é que o código está ficando muito simples, as vezes me questiono se está funcionando, rodo os testes e está ok. Quando deixamos para escrever o teste depois, temos reparado que a cobertura dos testes é inferior e o código mais complexo em relação a escrever testes antes. 

Valeu!

2008/11/17 Rafael Izidoro <raf...@gmail.com>

[fabioma...@gmail.com]

Tudo bem João?

Você poderia mostrar seu Case em nossa 4º reuinão, o que acha?

Abs
Fábio Margarito

On 18 nov, 13:54, "João Carlos Clementoni Silva" <joa...@gmail.com>
wrote:

> Olá,
> Na equipe que trabalho utilizamos o TDD na fase desenvolvimento. Não temos
> uma fase formal de modelagem. Modelamos quando é necessário pensar sobre o
> problema. Como utilizamos os padrões envolvidos no DDD, o desenvolvedor não
> tem muito o que inventar na arquitetura.
>
> Pra gente o TDD tem ajudado a fazer apenas o necessário para o código passar
> no teste. O resultado que tem acontecido é que o código está ficando muito
> simples, as vezes me questiono se está funcionando, rodo os testes e está
> ok. Quando deixamos para escrever o teste depois, temos reparado que a
> cobertura dos testes é inferior e o código mais complexo em relação a
> escrever testes antes.
>
> Valeu!
>

> 2008/11/17 Rafael Izidoro <raf4...@gmail.com>

>
>
>
>
>
> > Existe um framework BDD em ruby chamado RSpec. Andei fazendo umas
> > pesquisas e vi que criaram algo parecido para .NET, chamado NSpec

> >http://nspec.tigris.org/. Um video interessante sobre o assunto pode
> > ser visto no RailsEnvy
> >http://www.railsenvy.com/2007/10/4/how-i-learned-to-love-testing-pres...

> ...
>
> mais »- Ocultar texto entre aspas -
>
> - Mostrar texto entre aspas -

[João Carlos Clementoni Silva]

Oi Fábio,

A reunião é realizada em São paulo certo? Eu sou de Brasília. Outra coisa também é que começamos há pouco tempo com a prática do TDD. Tem funcionado bem mas não considero ainda um case de sucesso. Quando tivermos com experiência agente pensa numa forma de mostrar o case. 

Valeu,

2008/11/18 fabioma...@gmail.com <fabioma...@gmail.com>

[Fabio Margarito]

Sem problemas João.  Agradeço a sua atenção e por participar do grupo.

 

abs