TDD substitui ou complementa modelagem?

Assuntos Gerais Agile
#21

[quote=rogelgarcia][quote=Hebert Coelho]Mas tdd é >>>>>unitário<<<< o próprio nome diz.
Se você quer teste da arquitetura, vá para outros testes como o de integração. uai![/quote]

Então… seguindo esse raciocínio… o que acontece…

Você tem uma funcionalidade. Então, você cria um teste. Faz todos os procedimentos até ele passar.
Depois, pega outra funcionalidade, e repete o processo.
Faz isso mil vezes.
No final, onde está a arquitetura do sistema?

obs: Só estou fazendo o papel de advogado do diabo… [/quote]Mas mano, são papeis totalmente diferentes.
Com o TDD você testa os pedaços pequenos… Depois você junta tudo.

Você pode testar uma classe, depois testa persistência, depois testar a view…

Seria horrível e ridículo ter testes unitários apenas para as classes sem depois fazer algo que envolvesse integrações…

Não vejo como ligar TDD com problemas de arquitetura…

#22

[quote=x@ndy][quote=rogelgarcia]O autor do tópico quer a discussão… então… vou jogar uma bombinha… :twisted: rs

Comentem a seguinte afirmação:
Testes unitarios não testam a arquitetura do sistema. Como TDD é baseado em testes de pequenos pedaços funcionais, e de acordo com o que foi falado aqui, não deve-se planejar. Desenvolver com TDD é um facilitador para que seu sistema termine com uma arquitetura questionável.

[/quote]
Putz…nada haver! Esse tipo de afirmação embora lógica é uma falácia e demostra um total desconhecimento de TDD!

  1. Arquitetura não é só desenvolvimento. Envolve um conjunto de coisas. O desenvolvimento é somente parte é parte do processo arquitetural!
  2. O que TDD tem haver com falta de planejamento! Por quê usando TDD eu não posso fazer um planejamento? O que eu não tenho é uma documentação especificando exatamente o que deve ser implementado e isso não é planejamento é artefato da análise
  3. Da onde TDD é testar pequenos pedaços do sistema? Cada teste deve testar uma pequena parte, uma funcionalidade. Mas eu devo testar todas as funcionalidades, de modo que acabo por testar totalmente o sistema!
  4. A grande sacada do TDD é justamente ter um sistema com uma arquitetura coerente! Os testes de tão feedback rápido, indicando problemas na arquitetura do modelo ou na arquitetura geral do sistema.

O pessoal, se você quer saber oq é TDD tem que ler o livro do Kent Beckman - Que uma referência no assunto.[/quote]+1

#23

[quote=x@ndy]
Putz…nada haver! Esse tipo de afirmação embora lógica é uma falácia e demostra um total desconhecimento de TDD![/quote]

Se tem lógica… tem a ver!! Não é não? rs

Eu não defini o que é arquitetura. O ponto não é esse. De qualquer forma, não disse nada contrariando essa frase.

Quote xandy->“nada para TDD é necessário planejar”.

Veja minha frase: “TDD é baseado em testes de pequenos pedaços”. Eu não disse que é apenas testar pequenos pedaços, ou apenas uma parte do sistema. Um sistema totalmente testado pode ser baseado em testes de pequenos pedaços. Logo, minha afirmação está correta.

Como um teste unitário informa sobre problemas na arquitetura, se esse não é o propósito dele?

Você falou falou e pouco contestou da minha afirmação…

E “Putz…nada haver!” não é argumento. rs

Acho que talvez você tenha levado pelo lado pessoal devido ao furor da sua resposta… Não leve pelo lado pessoal, só fiz um questionamento… :slight_smile:

#24

Estamos começando a nos entender… :slight_smile:

[quote]Mas mano, são papeis totalmente diferentes.
Com o TDD você testa os pedaços pequenos… Depois você junta tudo.

Você pode testar uma classe, depois testa persistência, depois testar a view…

Seria horrível e ridículo ter testes unitários apenas para as classes sem depois fazer algo que envolvesse integrações… [/quote]

Eu não estou discordando de nada… Mas considerando o que você falou

"Com o TDD você testa os pedaços pequenos… DEPOIS você junta tudo. "

Esse depois é o que eu estou chamando de arquitetura ruim. Pois, antes, o que você fez foi, gerar um punhado de testes para um punhado de funcionalidades. E onde ficou a arquitetura do sistema nessa história?

Nesse ponto: "Você pode testar uma classe, depois testa persistência, depois testar a view… "
Se você tem persistencia, view, que são conceitos “grandes” vamos dizer assim… Você já saiu do TDD, não?!
Primeiro você criou uma arquitetura… e não o teste. E o TDD não testa arquitetura (acho que isso é consenso na discussão).

Pode ter parecido que eu sou um hatter de TDD pela minha hipótese inicial picante. Mas não… não sou hater, e nem lover… Só estou criticando para ver se quem é a favor do TDD está considerando certas hipóteses…

#25

[quote=rogelgarcia]"Com o TDD você testa os pedaços pequenos… DEPOIS você junta tudo. "

Esse depois é o que eu estou chamando de arquitetura ruim. Pois, antes, o que você fez foi, gerar um punhado de testes para um punhado de funcionalidades. E onde ficou a arquitetura do sistema nessa história?[/quote]Desculpe, mas a inda não vejo lógica. Isso para mim está parecendo pão com durex. :lol: :lol: :lol:

Me explique então como testar arquitetura sem ter nenhum código? O.o

Se você não ter os métodos mais simples, como você terá uma arquitetura? O TDD você começa pelo simples, e depois vai para o complexo. E fora do TDD também!!!

Onde já se viu ter uma EJB + Hibernate com persistência em pleno funcionamento sem antes ter uma entidade e alguns métodos? O.o

#26

Não acho que seja possível… Mas você vai testar a arquitetura depois de ter todas as funcionalidades prontas???

De acordo com o TDD, a implementação começa no teste. Se a implementação começa no teste, a primeira coisa que você tem que implementar é uma funcionalidade. Desenvolvimento Bottom-Up. (acho que agora cheguei num ponto interessante… desenvolvimento bottom-up)

Como é que você começa implementando uma arquitetura?! Pela classe concreta ou pela interface?

Eu pelo menos, geralmente começo pela interface. Top-Down.

TDD é teste de métodos concretos. Ou seja, desenvolvimento baseado em testes de funções implementadas. Não dá pra desenvolver arquiteturas usando TDD pois a forma de desenvolver arquiteturas (top-down) e de testar (teste integração) é diferente da metodologia (bottom-up) e tipo de testes (teste unitário) propostos por TDD.

PS: O que é pão com durex?

#27

Não acho que seja possível… Mas você vai testar a arquitetura depois de ter todas as funcionalidades prontas???[/quote]
Pois é… então por isso creio que seu questionamento não foi válido…

[quote=rogelgarcia]De acordo com o TDD, a implementação começa no teste. Se a implementação começa no teste, a primeira coisa que você tem que implementar é uma funcionalidade. Desenvolvimento Bottom-Up. (acho que agora cheguei num ponto interessante… desenvolvimento bottom-up)

Como é que você começa implementando uma arquitetura?! Pela classe concreta ou pela interface?

Eu pelo menos, geralmente começo pela interface. Top-Down.

TDD é teste de métodos concretos. Ou seja, desenvolvimento baseado em testes de funções implementadas. Não dá pra desenvolver arquiteturas usando TDD pois a forma de desenvolver arquiteturas (top-down) e de testar (teste integração) é diferente da metodologia (bottom-up) e tipo de testes (teste unitário) propostos por TDD.[/quote]
Outro assunto… deixar o assunto para outra pessoa…

[quote=rogelgarcia]PS: O que é pão com durex?[/quote]Expressão mineira para coisa sem nexo. [=

I am out of here…

#28

Não acho que seja possível… Mas você vai testar a arquitetura depois de ter todas as funcionalidades prontas???

De acordo com o TDD, a implementação começa no teste. Se a implementação começa no teste, a primeira coisa que você tem que implementar é uma funcionalidade. Desenvolvimento Bottom-Up. (acho que agora cheguei num ponto interessante… desenvolvimento bottom-up)

Como é que você começa implementando uma arquitetura?! Pela classe concreta ou pela interface?

Eu pelo menos, geralmente começo pela interface. Top-Down.

TDD é teste de métodos concretos. Ou seja, desenvolvimento baseado em testes de funções implementadas. Não dá pra desenvolver arquiteturas usando TDD pois a forma de desenvolver arquiteturas (top-down) e de testar (teste integração) é diferente da metodologia (bottom-up) e tipo de testes (teste unitário) propostos por TDD.

PS: O que é pão com durex?[/quote]

Antes de começar: TDD não garante qualidade de arquitetura, nem qualidade de código, nem qualidade de nada. Ele ajuda, mas tudo isso depende mais das skills do programador do que de qualquer outra coisa.

Quanto a composicao da arquitetura de um sistema, voce pode usar TDD, mesmo desenvolvendo Top-Down, uma boa referência é http://www.manning.com/koskela/, tambem um bom livro sobre o assunto. Outra boa referência é http://www.amazon.co.uk/xUnit-Test-Patterns-Refactoring-Signature/dp/0131495054. Ambos falam sobre desenvolvimento top-down e bottom-up.

Sobre TDD e arquitetura: Primeiro, é difícil definir o que de fato é arquitetura, eu sempre imagino como integracao entre a aplicação e a infra-estrutura, depois se vai ser usado, e mesmo se vale a pena usar testes unitarios em cada passo da infra-estrutura de um sistema. Para testar arquitetura, testes de integração são mais úteis, na minha opinião, do que testes unitários cheios de mocks.

Mas o que me chamou atenção no seu comentário é que por achar que TDD não ajuda na arquitetura, ele automáticamente atrapalha, e a partir daqui eu não entendi mais nada. Os testes ajudam a manter o seu dominio limpo, fácil de entender e manter. E ali estarão os testes, independente da arquitetura pela qual voce optou, do framework, linguagem, servidor, sistema operacional voce vai usar, voce terá regras de negócio em algum lugar. E não é por voce partir de uma arquitetura top-down que as regras basicas de responsabilidade dos seus objetos deixarao de existir, que as operações sobre eles deixarao de existir, que os principios e boas práticas deixarão de existir.

E se voce tem esses objetos, suas operacoes sobre eles, a maneira como eles interagem entre si, em que TDD pode ferir a implementação disso?

Se voce se refere a arquitetura como, a arquitetura dos seu dominio, nesse caso TDD ajuda muito, mesmo top-down. Nada que impede que voce desenhe a interface de cima pra baixo, mesmo nao havendo implementação, ou com implementacao fake, para que passe nos testes e a cada passo va detalhando e implementando as partes menores, sempre usando testes.

Voce pode inclusive, eu uso bastante, integrar varias funcionalidades, com teste unitarios. Desde que consiga isolar e remover da sua regra qualquer coisa que precise de acesso externo, como banco de dados, arquivos, web services e etc…

Então, TDD atrapalha na arquitetura? Antes, o que é arquitetura? Mas seja lá qual for a sua resposta, acho pouco provável que atrapalhe.

#29

[quote=x@andy]
TDD é parte do desenvolvimento de software e não é tudo! É fundamental entender o dominio, ou seja, entender o negócio que você está implementando. (…) Você deve fazer de tudo para entender o dominio, não da para sair simplesmente programando. (…) Muito provavelmente eu criaria um rascunho com as classes que esse domínio tem. Mas seria apenas um rascunho algo que me ajuda-se a entender o problema. Um rascunho não é nd mais que um rascunho, se for feito em papel eu posso amassa-lo e joga-lo fora a qualquer momento e começar do zero (…) O problema é perder tempo precioso modelando classes, definindo métodos e depois ir para o código (…) Um modelo documental você tem que seguir fielmente um rascunho não, é uma ideia e se não deu certo joga fora ou altera! [/quote][quote=x@ndy]Você escreve os testes, ai pega o primeiro teste da lista e implementa![/quote]
Beleza, considero que essa explicação resolve a tal “contradição”. Inclusive já peguei uma falha minha aqui, essa parte de listar os testes antes eu tinha esquecido completamente! Não vinha fazendo isso, e nem lembrava que é um procedimento que faz parte do TDD. Curiosamente, é algo que só confirma a necessidade de um pequeno planejamento…

[quote=Yvga]
É muito dificil julgar baseado em alguns parágrafos sem ver nada de código, mas o teu comentário me passa a impressão de que você está com problemas de atribuição de responsabilidade nos seus objetos. Se você pega a funcionalidade completa e tenta testar e tem dificuldade em separar isso, talvez elas estejam emaranhadas umas nas outras. (…) Ainda que ela, por força da regra de negócio, seja extremamente complexa, ela irá executar uma série de tarefas bem definidas. Se cada passo é bem definido, você tem em cada um desses passos, algo simples (…)[/quote]
Valeu, vou pensar melhor em tudo isso na próxima vez que tentar implementar uma funcionalidade usando TDD. Se tiver dificuldade eu volto em um novo tópico mostrando um caso concreto para vocês darem uma ajuda.

#30

YvGa: Boa resposta… Está mais centrada em responder o meu questionamento.

Hebert Coelho: Acho que houve uma confusão. Eu não disse que era obrigatório testar a arquitetura. Eu disse que TDD não testa a arquitetura. E que de acordo com o sistema de desenvolvimento TDD, não se teria o desenvolvimento da arquitetura adequadamente. Pelas diferenças de filosofia que expliquei anteriormente. Mas, o YvGa disse que mesmo com TDD é possível implementar a arquitetura de forma satisfatória.

#31

[quote=rmendes08]Bom dia, há algum tempo eu tenho lido e praticado (um pouco) de TDD, muito embora até hoje não tenha conseguido trazê-lo totalmente para a minha realidade profissional. Nessa minha pouca experiência, percebo que: mesmo que os testes ajudam na especifação do sistema, rascunhar um UML ou outro vem muito a calhar, especialmente na hora de entender o domínio do sistema ser construído sair aquele 1o teste.

Sendo assim, o que vocês acham ?

obs: haters de TDD e testes unitários são bem vindos! :twisted: [/quote]

Primeiro que tudo não confundir TDD com Test First. Test First é um prática de orientação a testes, vinda do XP que significa que primeiro vc escreve o código que testa e depois vc escreve a funcionalidade sendo testada.
TDD é um modelo de design assistido por testes. A ideia é usar o Test Fisrt e depois iterar várias vezes, com refactoring até vc ter um bom design. Isto só é possivel se vc sabe os casos de uso com antecedência. O TDD não é explorativo.

TDD não substitui o cérebro. O verdadeiro design acontece no cérebro. O TDD é mais uma forma de experimentar se suas ideias são válidas, antes de programar as funcionalidades. Programando o cliente do código primeiro (que é o teste) vc identificada pontos que escaparam de sua analise mental. E como o processo é iterativo à um retroalimentação em que o seu design verdadeiro ( o que está na sua cabeça) vai sendo enrriquecido pela experiencia adquirida durante as sessões de TDD.

O Test First é um necessidade, diria, mas o TDD é apenas uma ferramenta - muito menos relevante que o Test First. Portanto, não confundir. E não se iludir que o TDD o levará ao software melhor simplesmente dando à manivela. Não funciona assim, A repetição não leva à perfeição. É necessário conhecimento de design real e embutir esse conhecimento (patterns por exemplo, ioc, separação de responsabilidade, etc…) para realizar o design de fato.

#32

[quote=rogelgarcia]YvGa: Boa resposta… Está mais centrada em responder o meu questionamento.

Hebert Coelho: Acho que houve uma confusão. Eu não disse que era obrigatório testar a arquitetura. Eu disse que TDD não testa a arquitetura. E que de acordo com o sistema de desenvolvimento TDD, não se teria o desenvolvimento da arquitetura adequadamente. Pelas diferenças de filosofia que expliquei anteriormente. Mas, o YvGa disse que mesmo com TDD é possível implementar a arquitetura de forma satisfatória.

[/quote]

Na verdade, alguns autores defendem que a construção de um sistema deve começar com um teste end-to-end (teste de ponta-a-ponta) que teria como objetivo justamente testar a arquitetura. Um teste end-to-end é um teste automatizado feito em um ambiente semelhante ao ambiente de produção (por exemplo, um .war deployado em servidor de aplicação real, apontado para um banco de dados real) e que deve exercitar desde a interface até banco de dados (ou outra fonte de dados que seja).

Acho que alguns pontos comuns do que discutimos até agora:

1 - TDD não trata exclusivamente de testes unitários: quando necessário podemos escrever testes de integração ou outros tipos de teste.

2 - TDD não exclui outras ferramentas para o entendimento do domínio: rascunhos de diagramas (UML, DER’s, etc.) , entrevistas com clientes, estórias e casos de usos ainda são válidos

3 - Planejamento ainda é necessário: não aquele planejamento detalhado e que deve ser seguido à risca, mas dado uma estória ou caso de uso, é preciso pelo menos planejar quais testes devem ser escritos para implementar a funcionalidade.

Bom, o ponto que realmente me intriga é a questão desenvolvimento top-down x bottom-up. Na minha pouca experiência, o desenvolvimento top-down se mostrou muito melhor do que o desenvolvimento bottom-up, por um simples motivo: com um desenvolvimento top-down você é muito mais objetivo. Você concentra seu esforço unicamente em desenvolver a funcionalidade necessária, seja ela uma aplicação com interface, um serviço ou API. Mesmo que você divida a implementação em funções e classes, cada função ou classe terá somente o código necessário para aquela funcionalidade. Já tentei, na faculadde, fazer um sistema no estilo bottom-up. O resultado foi que eu perdi um tempo enorme implementando funções e sobrecargas que nunca seriam usadas.

Mas qual a ligação com o TDD ?

Bom, se seguirmos a linha de desenvolvimento top-down com o TDD, começaríamos então com o teste de interface (ou teste end-to-end) , e seguiríamos com teste de granularidae mais fina até a etapa para implementar as classes de domínio do sistema, onde prevalecem os testes unitários; Por outro lado, testes de interface ou testes de integração muitas vezes são difíceis de escrever e manter. Sendo assim, é mais interessante concentrar o esforço de testes nos teste unitários e nas classes de domínio, que de certa maneira, porém, receio que isso encorajar um estilo bottom-up de desenvolver.

Fui claro ?

#33

…

#34

Realmente o TDD usa um estilo diferente do bottom-up ou do top-down. Ele usa um esquema mais inside-out. Começa pelo Dominio ( e o domínio é muito grande, entidades, validações, especificações, serviços, repositórios, ou seja, o core). Depois do dominio ( que é onde o TDD realmente pode brilhar porque um junit da vida resolve, vamos para as integrações. A integrações dos repositoros ao banco de dados (seja SQL ou NoSQL ou uma mistura dos dois). Aqui começam as dores de cabeça nos testes. Porque banco = estado e estado é uma porcaria para testes. AS realações entre as entidades começam a pesar, etc…

Do outro lado temos a apresentação. É gráfica ? ou é um serviço ? ou ambos ? Talvez precisamos de uns façadades. Depois o cliente. Se for ui temos que testar os gestos do usuário … chato. Se for serviço temos que simular a chamada vinda de fora. Mais simples. Nos dois casos é preciso ter muita noção dos casos de uso porque só assim é possivel criar fluxos de teste que realment testam alguma coisa. Aqui também pode haver uma dependência com o estado, e isto tb é problemático.

Porem TDD não é cobertura de testes. O Objetivo do TDD não é cobrir todos os testes necessários. Isso é Test First. O objetivo do TDD é auxiliar o desenvolvimento e o design. Mesmo após o design ter sido definido mais testes são adicionados, mas isso já não é TDD. Não é porque se criam testes que fazemos TDD. isso é só o T. Faltou os DD.

#35

Posso estar viajando, mas pra mim o que você diz ser Test First é o que eu vejo como o TDD.

Já que o ‘D’ ali no meio corresponde a Driven, que significa conduzido ou orientado a.

O próprio Kent Beck define o ciclo do TDD assim: [quote=“Kent Beck”]Test-driven development (TDD) is an alternative programming workflow where features are divided into a series of automated tests. The tests are chosen so that satisfying the spirit of all the tests implies that the feature as a whole works correctly. The cycle goes like this:

Write the next test (while several tests may be outlined, only one is written at a time)
In pessimistic languages, add enough stubs so the test compiles. It should fail when run.
Refactor, if necessary, to prepare for the implementation.
Change the logic of the system so the test passes.
Refactor to eliminate duplication and other excess complexity
Repeat until no more of the tests implied by the feature would fail. Then the feature is complete.[/quote] Não é isso que você disse que é Test First? Ou estou enganado.

Eu sou bem novo nesse conceito, portanto desculpem se falei alguma bobagem, é que como o Kent Beck foi o criador dos 2 (XP e TDD), eu imagino que ele possa ter pensado na mesma coisa, não sei.

#36

[quote=Rodrigo Sasaki]Posso estar viajando, mas pra mim o que você diz ser Test First é o que eu vejo como o TDD.

Já que o ‘D’ ali no meio corresponde a Driven, que significa conduzido ou orientado a.

O próprio Kent Beck define o ciclo do TDD assim: [quote=“Kent Beck”]Test-driven development (TDD) is an alternative programming workflow where features are divided into a series of automated tests. The tests are chosen so that satisfying the spirit of all the tests implies that the feature as a whole works correctly. The cycle goes like this:

Write the next test (while several tests may be outlined, only one is written at a time)
In pessimistic languages, add enough stubs so the test compiles. It should fail when run.
Refactor, if necessary, to prepare for the implementation.
Change the logic of the system so the test passes.
Refactor to eliminate duplication and other excess complexity
Repeat until no more of the tests implied by the feature would fail. Then the feature is complete.[/quote] Não é isso que você disse que é Test First? Ou estou enganado.
[/quote]

Isso é o ciclo de testes. é O T. Cadê o Development ?
Está na frase "Change the logic of the system so the test passes."
Isto é muito vago. Isto não é Desenvolvimento.

O Beck tem este problema de super-iteração. Se vc seguir à risca o que ele escreveu, vc começa com um main vazio depois coloca int = 1. Não funciona. depoiis int = 5 etc… até vc entender que precisa de System.out.println() e assim vai.
Ele mesmo já falou (eu vi num video não tenho a referencia) que não é isto que ele quiz dizer. Existe um design prévio que acontece na sua cabeça. Vc já sabe que tem que chamar println , já sabe que tem que usar um for. então vc coloca isso no código.
Ai vc usa o ciclo. Quando vc chegan o verde vc pára ? Sim. Vc pssa para o proximo teste. Ai o próximo teste exige que afora o for fique numa classe. E ai vc refatora o primeiro teste tb. E assim via. Quando chegar no ultimo teste, em tese, todos os testes estão refatoradsos para a mesma logica e modelo e funcionam. Vc atingiu um design supremo ? Não. Vc atingiu o design que é mínimo para aqueles testes. Para melhorar o design vc precisa de mais requisitos e portanto mais testes.

Com Teste First, apenas, vc tem o modelo desenhado na sua cabeça. Vc vai lá e implementa. Só que começando pelos testes. Mas por exemplo, vc já sabe que tem a classe X e Y, e como elas se relacionam etc… O teste pode identificar algunss detalhes que precisam ser melhorados (normalmente isolamento e inversão de dependência), mas o teste não é usado para desenvolver. Ele é , ora bem , um teste. Ele testa que a sua ideia funciona. Ele não provoca a ideia, ele provoca modificações.

TDD inclui Teste First, mas Test First não inclui TDD.

TDD é como CAD ( computer assisted design) e poderia-se chamar Test Assisted Development

Pensando de outa forma, no modelo padrão vc quer colocar um pattern X vc vai e coloca. Em TDD vc não faz isso. Vc escreve um código qualquer e depois quando for refactorar é que vc identifica o padrão e o usa. O TDD é reactivo e não pro-activo. E isso pode ser bom quando vc quer ser minimalista como o Beck gosta de ser, mas implica em muitos passos desncessários. Ai ele fala que a pessoa pode pular para o passo que deseja ( no caso, pode colocar o padrão logo de inicio). Mas isso para mim não é desenvolvimento assistido, é simplesmente ter uma ideia e colocar um teste à volta dela (Test First).

#37

Estou aqui lendo o livro do Kent sobre TDD para poder opinar melhor… olha que frase legal que encontrei…

“This is the opposite of architecture-driven development”

:slight_smile:

#38

[quote=rogelgarcia][quote=x@ndy]
Putz…nada haver! Esse tipo de afirmação embora lógica é uma falácia e demostra um total desconhecimento de TDD![/quote]
Se tem lógica… tem a ver!! Não é não? rs
[/quote]

Não! Por isso é uma falácia! Um exemplo. A algum tempo foi feito uma pesquisa na Universidade Federal de Pelotas na qual foram utilizados ratos que foram alimentados com grãos de feijões crus o que levou ao óbito desses. A pesquisa descobriu que existe uma proteina que matava esses animais, porém durante o cozimento ela se transformava em outra coisa que não afetava os seres humanos! Bom, a partir disso surgiu uma estória, muito difundida na internet, que feijão cru poderia ser usado como raticida, pois se na pesquisa os ratos morreram ao comerem feijões porque se eu espalhar pela casa eles não vão comer e morrer?!!

O argumento de que o feijão seja um raticida (embora tenha por trás algo lógica, uma pesquisa) é uma falácia! “E por que?” Porque os ratos não comem feijão! Os anos de evolução levaram esses animais a evitar esse tipo de alimento, pois eles instintivamente sabem que vão morrer! Mas por quê na pesquisa eles comeram? Porque foi feita sob um ambiente controlado. Provavelmente eles só forneceram feijões como alimento e entre morrer de fome e comer o feijão o rato comeu o feijão!

O seu argumento é muito similar. A partir dos comentários feitos vc desenvolveu uma teoria, que embora tenha um “contexto” lógico é uma falácia! Aqui é importante notar a palavra contexto e não embasamento! Sua teoria foi baseada em um contexto lógico assim como na estória do rato, mas não tem um embasamento lógico (não foi feita nenhuma pesquisa em cima, por exemplo) para determinar que ela está certa!

Eu não defini o que é arquitetura. O ponto não é esse. De qualquer forma, não disse nada contrariando essa frase.[/quote]
Ai que tá! Sem definir arquitetura e sem dizer em aspecto que TDD afeta a arquitetura, isso perde o valor pois se torna algo muito vago! Isso me lembra do Hibernate! Antes mesmo de mexer com ele eu ouvia dizer que era lento, que não dava para usar pq era lento, etc. Só que ninguém conseguia dizer pq era lento! Na verdade eu comecei a mexer e nunca foi lento! A unica coisa que me faz pensar que poderia deixar ele lento era “carregar o banco inteiro” através de referências de classes. Mas ai tem Lazy… Bom a discussão não essa! Mas os dois tem algo parecido, pois expõem uma opinião sem conhecimento real do assunto

Quote xandy->“nada para TDD é necessário planejar”. [/quote]
Eu escrevi isso errado, deve se ignorar a palavra nada, mas no contexto geral eu disse que é necessário planejar e isso era feito se escrevendo quais testes devem ser ser implementados. Na verdade a última frase eu digo exatamente isso. . vou corrigir lá…

Veja minha frase: “TDD é baseado em testes de pequenos pedaços”. Eu não disse que é apenas testar pequenos pedaços, ou apenas uma parte do sistema. Um sistema totalmente testado pode ser baseado em testes de pequenos pedaços. Logo, minha afirmação está correta. [/quote]
Realmente, por algo ser algo vago, entendi que você queria dizer que o problema era pq só se testava parte do sistema!

Como um teste unitário informa sobre problemas na arquitetura, se esse não é o propósito dele?
[/quote]
Por que você não está simplesmente testando algo que você ou outra pessoa implementou. Durante os testes você também está modelando. Os testes são seguidos de refatorações e ao refatorar você muda o sistema e o vai melhorando. Se você simplesmente testar código pronto pode se deparar com algo dificil de ser testado pois vai necessitar de um monte de classes para criar um testes, algo extremamente acoplado e sem qualquer coesão! Isso faz com que um simples teste necessite de um numero de enorme de de passos! Com TDD ao encontrar um acoplamento durante um teste você refatora de modo a corrigir o problema. Os testes também de tão feedback. Durante o a implementação você pode ter uma idéia que melhora o código, então refatora para isso e testa e continua o ciclo!

Bom o seu argumento também era muito pequeno e bem vago!

[quote=rogelgarcia]E “Putz…nada haver!” não é argumento. rs[/quote] Realmente é uma interjeição! Quis desmonstrar incredulidade…rsrsrsr :smiley:

De modo algum! O problema é que você destacou um problema que não existe de forma extremamente vaga. Quando realmente se conhece a finalidade de TDD você vê que isso que você está dizendo não faz o menor sentido!

#39

[quote=sergiotaborda]
Pensando de outa forma, no modelo padrão vc quer colocar um pattern X vc vai e coloca. Em TDD vc não faz isso. Vc escreve um código qualquer e depois quando for refactorar é que vc identifica o padrão e o usa. O TDD é reactivo e não pro-activo. E isso pode ser bom quando vc quer ser minimalista como o Beck gosta de ser, mas implica em muitos passos desncessários. Ai ele fala que a pessoa pode pular para o passo que deseja ( no caso, pode colocar o padrão logo de inicio). Mas isso para mim não é desenvolvimento assistido, é simplesmente ter uma ideia e colocar um teste à volta dela (Test First).[/quote]

Certo, Sergio, entendo seu ponto de vista, mas deixa eu fazer uma defesa ao Beck, ou uma acusação, já que o livro dele não deixa isso claro. Mas foi a maneira que eu sempre entendi, lendo principalmente ele e os outros dois autores que eu citei no meu post anterior.

Não existe um jeito certo de começar a implementação, você pode começar por onde quiser, outside-in ou inside-out (o que pra mim parece o mesmo que top-down ou bottom up), você pode desenhar primeiro a interface de uma calculadora, pode implementar as teclas com infra-estrutura fake e ir aos poucos descendo para as operacoes matematicas. Ou então você pode fazer inside-out, começar pelas operações e vir para as teclas e a interface depois.

Mas o que você não pode, nem vai conseguir, de jeito nenhum, e é o que parece muita gente ter entendido da proposta do TDD é planejar inside-out. Não se pode planejar inside-out, não é possível imaginar uma calculadora começando simplesmente pelas operações matemáticas, sem pensar em como um ser humano irá interagir com ela (não se iludam pela aparencia de que no caso de uma calculadora seria possivel). Eu não posso somar dois numeros, se eu ainda nem sei se serão inteiros, pontos flutuantes, binários ou seja lá que formato for quando chegar a hora de fazer a soma. Você precisa, necessáriamente, pelo menos de uma boa noção do todo para começar a implementar, seja de um jeito ou de outro.

O planejamento não é top-down, ou bottom-up, ele precisa de integridade, precisa das teclas tanto quanto das operações, preciso ser único e bem definido, ainda que só um esboço, um esboço claro. E isto nada tem a ver com TDD, TDD trata de código, quando se diz que TDD ajuda na melhora do design é no design do código e não da solução em si. Você pode ter um código excelente para uma porcaria de solução, você pode errar o planejamento completamente e ainda ter centenas de testes comprovando a besteira que você fez.

Para implementar você tem que necessariamente planejar, e nunca ninguem, seja ágil, lean, tradicional, cascata ou scrumzeiro, disse que não é necessario planejamento antes de implementar. O que se discute é o tempo gasto nesse planejamento e a reverência que se faz a ele nos métodos tradicionais. Mas você vai sim, planejar antes de implementar, ainda que seja com um esboço do modelo na sua cabeça, ou um rabisco no papel ou no quadro, mas vai ter algum planejamento.

Ninguem comeca com um void main, é preciso ter uma boa ideia do que vai ser feito e já alguma noção do como. Tendo uma ideia do que vai ser feito e uma noção do como, tanto faz começar de dentro ou de fora, tanto faz começar pelas camadas mais altas e descer, como pelas mais baixas e subir.

E seja qual for o caminho que voce escolher a partir dali, TDD não vai te atrapalhar, muito pelo contrário, porque uma vez tendo “rascunhada” a solução, você passa para a implementação que é onde ele brilha.

#40

x@andy, meu questionamento sobre TDD facilitar uma arquitetura ruim faz tanto sentido, que no próprio livro do criador do TDD ele diz que TDD é oposto a desenvolver direcionado a arquiteturas.

Seguindo TDD (e eu li isso no livro), decisões de design são tomadas tardiamente no desenvolvimento. Tomar decisões importantes de design tardiamente, acho que não preciso convencer que é problemático. Um fato que contribui para essa afirmação, é que TDD é fortemente baseado em refatorações. Isto é, você fatalmente implementará algo ruim e DEPOIS ajusta. Por isso eu falei, TDD é um facilitador para arquiteturas ruins. Pode ser, que depois de ter implementado um monstro de funcionalidades chegue a conclusão que o design do sistema não comporta a nova funcionalidade. E aí você fará uma refatoração para atender esse novo requisito.