Pessoal, iniciei há algumas semanas o meu primeiro emprego em desenvolvimento Java e na empresa desenvolvemos usando TDD. Tive o primeiro contato com TDD nos últimos dias e estou com grande dificuldades em assimilar, ou melhor, de pensar e desenvolver com TDD. E o aprendizado ficará por minha conta, vou ter que correr atrás.
Gostaria de saber dos colegas se vcs também enfrentaram dificuldades com TDD e se demorou muito tempo para vocês desenvolveram naturalmente usando TDD?
Leia um livro.
É o melhor que você pode fazer. Tem o da casa do Código, tem também o JUnit in Action e o TDD Kent Beck (que é um dos idealizadores).
[quote=Hebert Coelho]Leia um livro.
É o melhor que você pode fazer. Tem o da casa do Código, tem também o JUnit in Action e o TDD Kent Beck (que é um dos idealizadores).[/quote]
O livro da casa do código sobre TDD já tenho e estou lendo no momento 
Inclusive o seu livro sobre JSF já está na minha lista de leitura. Vou procurar esse do Kent Beck.
[quote=norbAns][quote=Hebert Coelho]Leia um livro.
É o melhor que você pode fazer. Tem o da casa do Código, tem também o JUnit in Action e o TDD Kent Beck (que é um dos idealizadores).[/quote]
O livro da casa do código sobre TDD já tenho e estou lendo no momento Inclusive o seu livro sobre JSF já está na minha lista de leitura. Vou procurar esse do Kent Beck.[/quote]Uia, valeu.
TDD é com conceito de louco (a primeiro momento). Depois que se pega a prática é possível ver que tudo fica mais fácil.
Só de você fazer um código e rodar o teste na hora já é muito bom. Você sabe onde e como vai impactar.
Você pode ler sobre os conceitos, mas não vai aprender a fazê-lo lendo livros.
Pratique muito, vá em dojos, code com pessoas que já tem prática. Quanto mais você praticar tdd, mais rápido vai dominá-la. Dojos são excelentes ambientes para tal. Você também pode fazer um curso, um instrutor pode te passar várias manhas, mas novamente, você precisa praticar muito.
[quote=Hebert Coelho][quote=norbAns][quote=Hebert Coelho]Leia um livro.
É o melhor que você pode fazer. Tem o da casa do Código, tem também o JUnit in Action e o TDD Kent Beck (que é um dos idealizadores).[/quote]
O livro da casa do código sobre TDD já tenho e estou lendo no momento Inclusive o seu livro sobre JSF já está na minha lista de leitura. Vou procurar esse do Kent Beck.[/quote]Uia, valeu.
TDD é com conceito de louco (a primeiro momento). Depois que se pega a prática é possível ver que tudo fica mais fácil.
Só de você fazer um código e rodar o teste na hora já é muito bom. Você sabe onde e como vai impactar. [/quote]
Concordo com o Herbert.
Como eu sempre digo, TDD eh muito simples, se está complicado é porque os conceitos de responsabilidade, desacoplamento, coesão e as coisas mais básicas de orientação a objetos ainda não estão claras na sua cabeça.
Implementar TDD não é fácil, mas porque OO não é fácil, embora pareça a princípio.
Parodiando uma frase atribuida a Descartes: Conhecimento em Orientação a Objetos é a coisa mais bem distribuída entre os programadores, ninguém acha que precisa mais do que já tem.
Estude Orientação a Objetos, muito e um pouco de TDD que as coisas saem naturalmente.
Sinceramente, o melhor jeito de aprender TDD é pair programming (Com alguém mais experiente).
[quote=Hebert Coelho]Leia um livro.
É o melhor que você pode fazer. Tem o da casa do Código, tem também o JUnit in Action e o TDD Kent Beck (que é um dos idealizadores).[/quote]
Concordo! Durante muito tempo achei que TDD era sinônimo de testes unitários, de implementar e ai criar um testes e somente entendi o conceito depois de ler o livro do Kent Beck (Desenvolvimento Guiado Por Testes). Já nos primeiro capítulos desse livro e vi que fazia tudo errado e me deu um está-lo.
O único problema que vejo de TDD é que você tem que entender bem de OOP, senão não vai ter como, pois para aplicar TDD efetivamente você terá que criar classes com baixissimo acoplamentos, pois classes muitos acopladas demandam um uso excessivo de Mocks que dificultam em muito o desenvolvimento. Com TDD você vai ganhar alta coesão de suas classes pois vai implementar somente o que elas realmente devem fazer.
Discordo, acho que os conceitos são importantes
Ai eu já concordo, acredito que lendo e colocando em prática você começara a ter o dominio do TDD
Eu aprendi sozinho! Assim que comecei a ler o livro do Kent comecei a colocar em prática os conceitos e como o livro é muito simples é rápido de ler e praticar.
A meu TDD é que nem aprender a programar, você só aprende realmente praticando, mas se você não tiver os conceitos básicos não evolui!
Discordo, acho que os conceitos são importantes
Ai eu já concordo, acredito que lendo e colocando em prática você começara a ter o dominio do TDD
Eu aprendi sozinho! Assim que comecei a ler o livro do Kent comecei a colocar em prática os conceitos e como o livro é muito simples é rápido de ler e praticar.
A meu TDD é que nem aprender a programar, você só aprende realmente praticando, mas se você não tiver os conceitos básicos não evolui!
[/quote]+1 em tudo. [=
[quote=YvGa]
Como eu sempre digo, TDD eh muito simples, se está complicado é porque os conceitos de responsabilidade, desacoplamento, coesão e as coisas mais básicas de orientação a objetos ainda não estão claras na sua cabeça.
Implementar TDD não é fácil, mas porque OO não é fácil, embora pareça a princípio.
Parodiando uma frase atribuida a Descartes: Conhecimento em Orientação a Objetos é a coisa mais bem distribuída entre os programadores, ninguém acha que precisa mais do que já tem.
Estude Orientação a Objetos, muito e um pouco de TDD que as coisas saem naturalmente.[/quote]
Concordo. TDD vai fazer que você tenha uma proliferação de classes enxutas e isso é estranho, pois inicialmente estamos acostumados com classes com excesso de responsabilidade e altamente acopladas a outras classes. As vezes é o extremo, uma classe possui uma dezena de responsabilidades e a outra não faz absolutamente nada a não ser conter os dados (as chamadas classes anêmicas) que acarreta em uma arquitetura praticamente procedural, díficil de testar e evoluir!
A idéia é fazer o teste antes do código, da para fazer algo “parecido” que eu uso codificando, voce “usa” metodos que ainda nao existem nas classes e depois vai la e cria.
:?: Não entendi nada :?:
Seriam métodos Stubs?
:?: Não entendi nada :?:
Seriam métodos Stubs?[/quote]
Eu entendi hehehe, eu faço isso as vezes também.
Ao desenvolver a lógica de um método, percebo que fica melhor se eu criar uma outra classe, com um método nela, pra deixar tudo mais organizado.
Só que ao invés de criar a classe, eu continuo escrevendo meu método como se a classe já estivesse criada, depois vou lá e crio ela de verdade
:?: Não entendi nada :?:
Seriam métodos Stubs?[/quote]
Eu entendi hehehe, eu faço isso as vezes também.
Ao desenvolver a lógica de um método, percebo que fica melhor se eu criar uma outra classe, com um método nela, pra deixar tudo mais organizado.
Só que ao invés de criar a classe, eu continuo escrevendo meu método como se a classe já estivesse criada, depois vou lá e crio ela de verdade :)[/quote]
Ah! Sim! Raramente faço isso, mas é valido primeiro cria a implementação mais simples que funciona e depois refatora! Nesse caso o ideal é anotar a refatoração como um novo teste para posterior implementação. Assim a implementação da nova classe fica condicionada e protegida dentro desse novo teste.
[quote=x@ndy]A sim, raramente faço isso, mas é valido primeiro cria a implementação mais simples que funciona e depois refatora! Nesse caso o ideal é anotar a refatoração como um novo teste para posterior implementação. Assim a implementação da nova classe fica condicionada e protegida dentro desse novo teste.[/quote]I mano, mas o TDD pega o contrário.
Primeiro consiga um vermelho.
Depois um verde (agora que entra o código do método)
Refatore.
[quote=Hebert Coelho][quote=x@ndy]A sim, raramente faço isso, mas é valido primeiro cria a implementação mais simples que funciona e depois refatora! Nesse caso o ideal é anotar a refatoração como um novo teste para posterior implementação. Assim a implementação da nova classe fica condicionada e protegida dentro desse novo teste.[/quote]I mano, mas o TDD pega o contrário.
Primeiro consiga um vermelho.
Depois um verde (agora que entra o código do método)
Refatore.[/quote]
Sim Hebert, isso é um complemento do que ele falou anteriormente. O que ele disse é q cria o método e então descobre que esse método pode ser uma classe, mas mesmo assim ele cria a implementação óbvia desse método! A implementação óbvia é justamente para o obter a barra verde (Acredito que a barra vermelha tenha sido obtido rodando o método sem qualquer código)
[quote=x@ndy][quote=Hebert Coelho][quote=x@ndy]A sim, raramente faço isso, mas é valido primeiro cria a implementação mais simples que funciona e depois refatora! Nesse caso o ideal é anotar a refatoração como um novo teste para posterior implementação. Assim a implementação da nova classe fica condicionada e protegida dentro desse novo teste.[/quote]I mano, mas o TDD pega o contrário.
Primeiro consiga um vermelho.
Depois um verde (agora que entra o código do método)
Refatore.[/quote]
Sim Hebert, isso é um complemento do que ele falou anteriormente. O que ele disse é q cria o método e então descobre que esse método pode ser uma classe, mas mesmo assim ele cria a implementação óbvia desse método! A implementação óbvia é justamente para o obter a barra verde (Acredito que a barra vermelha tenha sido obtido rodando o método sem qualquer código)[/quote]
Ahmn… não .
No TDD, a idéia é a seguinte:
[]'s
[quote=Alexandre Saudate][quote=x@ndy][quote=Hebert Coelho][quote=x@ndy]A sim, raramente faço isso, mas é valido primeiro cria a implementação mais simples que funciona e depois refatora! Nesse caso o ideal é anotar a refatoração como um novo teste para posterior implementação. Assim a implementação da nova classe fica condicionada e protegida dentro desse novo teste.[/quote]I mano, mas o TDD pega o contrário.
Primeiro consiga um vermelho.
Depois um verde (agora que entra o código do método)
Refatore.[/quote]
Sim Hebert, isso é um complemento do que ele falou anteriormente. O que ele disse é q cria o método e então descobre que esse método pode ser uma classe, mas mesmo assim ele cria a implementação óbvia desse método! A implementação óbvia é justamente para o obter a barra verde (Acredito que a barra vermelha tenha sido obtido rodando o método sem qualquer código)[/quote]
Ahmn… não .
No TDD, a idéia é a seguinte:
[]'s
[/quote]
Pessoal, isso foi um complemento ao que ele falou, Vou tentar explicar melhor!
Eu crio um teste para calcular a media de um conjunto de valores de uma classe chamada Preços, por exemplo, na qual eu espero que a media retornada a seja 10!
Entao eu implemento o método média na classe preço (na verdade não pq o eclipse faz isso para mim ;)) que me retorna 0 e rodo meu testes ele falha, barra vermelha. Blz!
Começo a fazer a a implementação mais simples possível e ai e me toco que o calculo é complexo que é melhor transformar a média em um classe! Só que eu não paro e implemento a nova classe pois tenho um barra vermelha, então eu anoto a refatoração futura como um novo teste e continuo implementando, pois tenho que ver a barra verde. Termino rodo o teste e obtenho a barra verde. Blz.
Pego aquele teste marcado como a refatoração e implemento o teste para a classe média. Faço o ciclo até obter a barrar verde!
Após a barra verde do teste para a classe Média refatoro Teste da media dos Preços para utilizar a classe média e não um valor fixo seguindo o ciclo de TDD!
:?: Não entendi nada :?:
Seriam métodos Stubs?[/quote]
Eu entendi hehehe, eu faço isso as vezes também.
Ao desenvolver a lógica de um método, percebo que fica melhor se eu criar uma outra classe, com um método nela, pra deixar tudo mais organizado.
Só que ao invés de criar a classe, eu continuo escrevendo meu método como se a classe já estivesse criada, depois vou lá e crio ela de verdade :)[/quote]
É isso mesmo, e com os Content Assist do Eclipse fica até mais facil fazer surgir uma classe depois de propriamente escrita.
Para mim isso é um TDD sem teste hehehe