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[/quote]
Isso é uma má prática pois o teste primário se refere a outra lógica. A nova classe é uma consequência de uma refatoração e deve possuir testes próprios! Um exemplo é que ao criar uma nova classe não existem testes para as pré condições dos métodos dessas classes, então, digamos um método dessa nova classe que não pode receber um valor negativo não é testado podendo quebrar com a(s) invariante(s) da classe!
[quote=Marky.Vasconcelos]
É 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[/quote]
Acho que esse eh um dos pontos mais fortes do TDD, o fato de voce usar uma classe antes mesmo dela existir porque faz voce entender o que deve fazer antes de ficar batendo cabeça implementando.
Eu tambem uso mesmo em pontos onde não é possível/viável (no momento) ter testes unitários.
[quote=von.juliano]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]
Obrigado pelas indicações e tenho equilibrado a questão de aprender(qualquer coisa) conceitos através de livros e praticar realmente.
[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:
Escreva o teste (sem nem sequer haver a implementação que atenda ao teste).
Rode o teste (ele deve, obrigatoriamente, falhar - já que a implementação não existe).
Escreva a implementação.
Rode o teste.
Se o teste estiver falhando, arrume a implementação.
Uma vez que o teste estiver passando, refatore até atingir o nível “ótimo” da implementação (ou seja, uma implementação performática, concisa, fácil de ler, etc.)
[]'s
[/quote]
Não teria ai antes da etapa 3, uma etapa de escrever o mínimo de código possível para que o teste passe, nem que seja um return null? Ai sim, vc escreve o seu primeiro esboço de implementação e prossiga nas demais etapas?
Uma dúvida que tenho referente ao primeiro passo e que já vi sendo discutida fortemente na web, ao escrever um teste para um método que não existe, eu obtenho um compilation fail e não um test fail. Pelo menos usando o Visual Studio não dá nem pra sair desse ponto, no Eclipse acho que ele permite rodar forçando e ai dá a barrinha vermelha. Mas de qualquer forma é um compilation fail.
Bom, são coisas diferentes obviamente, mas para o TDD em essência não é importante que a lógica do teste falhe em vez do compilador reclamar?
[quote=Daniel_MV]Não teria ai antes da etapa 3, uma etapa de escrever o mínimo de código possível para que o teste passe, nem que seja um return null? Ai sim, vc escreve o seu primeiro esboço de implementação e prossiga nas demais etapas?
Uma dúvida que tenho referente ao primeiro passo e que já vi sendo discutida fortemente na web, ao escrever um teste para um método que não existe, eu obtenho um compilation fail e não um test fail. Pelo menos usando o Visual Studio não dá nem pra sair desse ponto, no Eclipse acho que ele permite rodar forçando e ai dá a barrinha vermelha. Mas de qualquer forma é um compilation fail.
Bom, são coisas diferentes obviamente, mas para o TDD em essência não é importante que a lógica do teste falhe em vez do compilador reclamar?
[/quote]
Isso é um ponto muito polêmico, qual o tamanho do passo a dar?
O tal dos baby steps pra mim devem ser usados como guia. Se você só vai escrever uma implementação pra passar no teste que retorne 0, pra depois fazer um if pra 2 testes, e aí 3 ifs pra 3 testes, mas já sabe a solução que irá resolver o problema, não precisa ir fazendo passo a passo, isso só vai tirar a sua produtividade.
Pra mim a ideia dos baby steps é te ajudar em cenários que você não conhece bem, lá você consegue ir devagar, tendo feedback, e desenvolvendo a solução mais simples possível. Agora em algo que você já tem domínio, na minha opinião você já pode dar passos um pouco maiores.
[quote=Rodrigo Sasaki][quote=Daniel_MV]Não teria ai antes da etapa 3, uma etapa de escrever o mínimo de código possível para que o teste passe, nem que seja um return null? Ai sim, vc escreve o seu primeiro esboço de implementação e prossiga nas demais etapas?
Uma dúvida que tenho referente ao primeiro passo e que já vi sendo discutida fortemente na web, ao escrever um teste para um método que não existe, eu obtenho um compilation fail e não um test fail. Pelo menos usando o Visual Studio não dá nem pra sair desse ponto, no Eclipse acho que ele permite rodar forçando e ai dá a barrinha vermelha. Mas de qualquer forma é um compilation fail.
Bom, são coisas diferentes obviamente, mas para o TDD em essência não é importante que a lógica do teste falhe em vez do compilador reclamar?
[/quote]
Isso é um ponto muito polêmico, qual o tamanho do passo a dar?
O tal dos baby steps pra mim devem ser usados como guia. Se você só vai escrever uma implementação pra passar no teste que retorne 0, pra depois fazer um if pra 2 testes, e aí 3 ifs pra 3 testes, mas já sabe a solução que irá resolver o problema, não precisa ir fazendo passo a passo, isso só vai tirar a sua produtividade.
Pra mim a ideia dos baby steps é te ajudar em cenários que você não conhece bem, lá você consegue ir devagar, tendo feedback, e desenvolvendo a solução mais simples possível. Agora em algo que você já tem domínio, na minha opinião você já pode dar passos um pouco maiores.[/quote] Exatamente isso.
Pessoalmente não considero como barra vermelha o código nem ter compilado. A meu ver a barra vermelha deve ser obtida através de um resultado inválido.
O tamanho dos passos dados acredito que dependa da confiança no que se está implementando. Se estou fazendo algo que considero complicado ou que a lógica não está bem esclarecida na minha cabeça vou devagar e faço a implementação mais óbvia possível para obter a barra verde (normalmente uma copia do código de teste para o resultado esperado). Com a barra verde refatoro para a solução normal removendo a duplicação. Caso eu já tenha confiança e tenha entendido bem o que devo fazer pulo direto para implementação normal!
É um bom ponto, de fato. Não sou nenhum especialista no assunto, mas acho que a idéia da compilação falhar seria “provar” (grandes aspas, aqui) que o método / classe / whatever não existe antes de começar. Mas acho que não existe resposta certa, pra isso.
Com Java, usando alguma IDE, eu já escrevo a classe e evito esses compilation fail. Mas escrevendo testes pra código javascript, python, ruby, onde eu normalmente uso um simples editor de texto, isto faz mais sentido.
Uma coisa muito produtiva que eu vi recentemente foi o testacular, framework para testes do angularjs. Ele fica rodando o tempo todo, basta você salvar o código que ele já roda. Aí você deixa ele rodando em background num lado da tela, e na outra vai escrevendo código. É simples, mas eu achei fantástico.
[quote=wagnerfrancisco]Com Java, usando alguma IDE, eu já escrevo a classe e evito esses compilation fail. Mas escrevendo testes pra código javascript, python, ruby, onde eu normalmente uso um simples editor de texto, isto faz mais sentido.
Uma coisa muito produtiva que eu vi recentemente foi o testacular, framework para testes do angularjs. Ele fica rodando o tempo todo, basta você salvar o código que ele já roda. Aí você deixa ele rodando em background num lado da tela, e na outra vai escrevendo código. É simples, mas eu achei fantástico. [/quote]
O SBT faz isso também, é muito interessante ter os testes rodando continuamente assim, é uma facilidade a mais na hora de desenvolver
[quote=Rodrigo Sasaki][quote=wagnerfrancisco]Com Java, usando alguma IDE, eu já escrevo a classe e evito esses compilation fail. Mas escrevendo testes pra código javascript, python, ruby, onde eu normalmente uso um simples editor de texto, isto faz mais sentido.
Uma coisa muito produtiva que eu vi recentemente foi o testacular, framework para testes do angularjs. Ele fica rodando o tempo todo, basta você salvar o código que ele já roda. Aí você deixa ele rodando em background num lado da tela, e na outra vai escrevendo código. É simples, mas eu achei fantástico. [/quote]
O SBT faz isso também, é muito interessante ter os testes rodando continuamente assim, é uma facilidade a mais na hora de desenvolver
O Maven não faz isso?[/quote]
Legal… não sei se o maven faz algo assim, sinceramente até hoje só sabia do testacular.
[quote=x@ndy][quote=Marky.Vasconcelos]
Para mim isso é um TDD sem teste hehehe[/quote]
Isso é uma má prática pois o teste primário se refere a outra lógica. A nova classe é uma consequência de uma refatoração e deve possuir testes próprios! Um exemplo é que ao criar uma nova classe não existem testes para as pré condições dos métodos dessas classes, então, digamos um método dessa nova classe que não pode receber um valor negativo não é testado podendo quebrar com a(s) invariante(s) da classe![/quote]
E quem disse que tenho testes?
Ainda não achei a maneira correta de testar comportamente de views através de iterações com usuario, e eu não digo estados de formulario, e sim de translate através do tempo baseado na força.
[quote]
Sim, isso ajuda muito, acho que esse é o essencial, o teste em si é para garantir qualidade.
Com certeza nem tudo dá para fazer com TDD, um outro exemplo é programação multithread!
[quote=Marky.Vasconcelos][quote]
Sim, isso ajuda muito, acho que esse é o essencial, o teste em si é para garantir qualidade.[/quote]
Isso não é verdade! O teste é mais que isso! Ele serve para projetar a logica que vai ser implementada e de dar um feedback que tudo esta certo. Para isso a lógica é implementada no código do teste! Um exemplo simples é o teste de uma média! Esse teste é um diminuto do que é o teste representa em TDD! Ali eu manipulo a logica da média e vejo como ela deve ser antes mesmo implementar o método. Na linha 6 eu digo que o que eu espero como média de 2 números é a soma deles divido por 2. A implementação disso no método resultado é um reflexo do que foi planejado no teste.
Esse teste com certeza não garante a qualidade pois posso fazer o método retornar 6 e o teste irá passar. No próprio livro do Kent Beck comenta sobre isso falando que implementou 6 testes para um problema e outra pessoa implementou 65! Como a idéia de testes em TDD é encontrar a solução para um problema ele não pode garantir que todos os problemas que possa ter com um objeto serão cobertos. Na verdade com os testes em TDD se “obtêm” qualidade e não se “garante” a qualidade!
[code] @Test
public void testaMedia(){
int valor1 = 10;
int valor2 = 2;
int mediaExperada = (valor1 + valor2) / 2
Class media = new Media(valor1, valor2);
assertEquals(mediaExperada, media.resultado())
}
[/code]Como o teste serve para projetar a lógica de alguma coisa (“Um meio para um fim, segundo Kent Beck”) então se eu tenho conhecimento da lógica eu não preciso criar um teste para ela! O exemplo acima é ótimo para isso também! Para que criar um teste para media de 2 números? Como sei como fazer isso posso passar direto para implementação, mas isso não vai ser considerado TDD, mesmo que eu pense antes em como implementar!
@Test
public void testaMedia(){
int valor1 = 10;
int valor2 = 2;
int mediaExperada1 = (valor1 + valor2) / 2
int mediaExperada1 = (8 + 8) / 2
Class media = new Media(valor1, valor2);
assertEquals(mediaExperada1, media.resultado())
assertEquals(mediaExperada2 new Media(8,8).resultado())
}
[quote=Marky.Vasconcelos]Por isso que o teste deveria ser:
[code] @Test
public void testaMedia(){
int valor1 = 10;
int valor2 = 2;
int mediaExperada1 = (valor1 + valor2) / 2
int mediaExperada1 = (8 + 8) / 2
Class media = new Media(valor1, valor2);
assertEquals(mediaExperada1, media.resultado())
assertEquals(mediaExperada2 new Media(8,8).resultado())
}
[/code][/quote]
Na verdade não! O que você fez ali se chama Triangulação em TDD e serve para dirimir duvidas com relação a lógica implementada! Como a lógica ali é tão simples que nem seria necessário utilizar TDD para cria-la faz muito menos sentido ainda utilizar Triangulação. Kent Beck beck fala sobre isso em seu livro:
O problema é que você ainda não entendeu o sentido do teste. O teste não serve apenas para validar a logica na qual pensamos ou garantir a qualidade. Se você usa para isso, o teste abaixo seria o suficiente:
@Test
public void testaMedia(){
assertEquals(6, new Media(10,2).resultado())
assertEquals(4, new Media(8,8).resultado())
}
Eu posso pensar na lógica e implementar esse teste e então criar a classe media e o método resultado segundo o ciclo de TDD, mas essa não a finalidade do teste e definitivamente não é TDD. O teste em TDD visa projetar a logica e garantir que ela está correta!
@Test
public void testaMedia(){
assertEquals(6, new Media(10,2).resultado())
assertEquals(4, new Media(8,8).resultado())
}
Isso era o mesmo que escrevi aqui rapidamente.
Mas de qualquer forma, escrever esses dois testes ajudaria a não implementar o Media#resultado() a retornar 6 e fazer o teste passar.
Vou procurar sobre triangulação conforme voce indicou.
Mas o conceito do TDD não está nesse teste escrito, é faze-lo antes de ter as classes que são testadas. É voce usar o que não existe e cria-lo depois, e esse o conceito que uso desenvolvendo mesmo sem testes.
Eu não sou ninguém para falar de testes, eu não uso com Android pelos motivos que eu disse. E nem mesmo de TDD pois só o que sei foram palestras e conversando com outros devs que levam isso na pratica.
@Test
public void testaMedia(){
assertEquals(6, new Media(10,2).resultado())
assertEquals(4, new Media(8,8).resultado())
}
Isso era o mesmo que escrevi aqui rapidamente.
Mas de qualquer forma, escrever esses dois testes ajudaria a não implementar o Media#resultado() a retornar 6 e fazer o teste passar.
Vou procurar sobre triangulação conforme voce indicou.
Mas o conceito do TDD não está nesse teste escrito, é faze-lo antes de ter as classes que são testadas. É voce usar o que não existe e cria-lo depois, e esse o conceito que uso desenvolvendo mesmo sem testes.
Eu não sou ninguém para falar de testes, eu não uso com Android pelos motivos que eu disse. E nem mesmo de TDD pois só o que sei foram palestras e conversando com outros devs que levam isso na pratica.[/quote]
Novamente, isso não é TDD! TDD não uma coisa simples, do tipo “Ah, construa um teste e depois implemente a lógica, seguindo os passos vermelho, verde refatore!”! Isso é uma coisa simplista, um resumo que o pessoal prega e acha que é TDD. O que você aprendeu como sendo TDD está errado e a culpa provavelmente não é sua pois todo munda acha que está usando TDD e não tem a menor ideia do que ele realmente seja. Digo isso pois apreendi TDD inicialmente em fóruns, blogs, etc. Quando comecei a colocar na pratica tive diversas dificuldades pois muitas vezes os testes eram complexos ou até mesmo impossíveis de serem implementados. Um outro erro que eu fazia era executar os testes em uma sequencia especifica. Só fui apreender o que realmente era TDD quando li o livro do Kent Beck! Sugiro a todos que leiam esse livro (e leiam inteiro) para entender o que é TDD!
@Test
public void testaMedia(){
assertEquals(6, new Media(10,2).resultado())
assertEquals(4, new Media(8,8).resultado())
}
Isso era o mesmo que escrevi aqui rapidamente.
Mas de qualquer forma, escrever esses dois testes ajudaria a não implementar o Media#resultado() a retornar 6 e fazer o teste passar.
Vou procurar sobre triangulação conforme voce indicou.
Mas o conceito do TDD não está nesse teste escrito, é faze-lo antes de ter as classes que são testadas. É voce usar o que não existe e cria-lo depois, e esse o conceito que uso desenvolvendo mesmo sem testes.
Eu não sou ninguém para falar de testes, eu não uso com Android pelos motivos que eu disse. E nem mesmo de TDD pois só o que sei foram palestras e conversando com outros devs que levam isso na pratica.[/quote]
Novamente, isso não é TDD! TDD não uma coisa simples, do tipo “Ah, construa um teste e depois implemente a lógica, seguindo os passos vermelho, verde refatore!”! Isso é uma coisa simplista, um resumo que o pessoal prega e acha que é TDD. O que você aprendeu como sendo TDD está errado e a culpa provavelmente não é sua pois todo munda acha que está usando TDD e não tem a menor ideia do que ele realmente seja. Digo isso pois apreendi TDD inicialmente em fóruns, blogs, etc. Quando comecei a colocar na pratica tive diversas dificuldades pois muitas vezes os testes eram complexos ou até mesmo impossíveis de serem implementados. Um outro erro que eu fazia era executar os testes em uma sequencia especifica. Só fui apreender o que realmente era TDD quando li o livro do Kent Beck! Sugiro a todos que leiam esse livro (e leiam inteiro) para entender o que é TDD![/quote]
O TDD nao eh simplista, ele eh simples mesmo e, a não ser que eu não esteja entendendo, o Mark não está discordando de você.
Além de que eu concordo com ele quando ele diz que o conceito de TDD é usar o código antes dele existir. Essa é a premissa principal, que inclusive dá nome a técnica (test first) e é esse conceito que te permite implementar a lógica do ponto de vista de um usuário da classe que está sendo criada/alterada. De quebra você tem um teste que garante que o resultado do que voce implementou era aquilo que você esperava que fosse.
Pra quem nunca ouviu falar, triangulação é uma prática na qual você cria um teste (por exemplo que te diz que a media de 2 e 4 é 3, faz com que seu método retorne 3 (return 3; ) e depois cria outro teste para o mesmo método dizendo que a média de 2 e 6 é 4. A partir dai a implementação que existe retornando 3 não é suficiente e você precisa alterá-la para que os dois testes passem.
Depois você escreve outro para outra situação e vai cercando a implementação com as possibilidades que existirem. É muito útil, mas em casos simples você pode dar passos maiores.
Voltando ao conceito de TDD eu sempre repito o mesmo, ele eh muito simples, muito fácil. Se está complicado é porque você tem problemas no código que está sendo testado, não nos testes.
Embora as premissas de TDD pareçam simples ela é uma das técnicas mais difíceis que já fiz tanto que no inicio é extremamente comum não segui-lo e, se você leu o livro do Kent Beck, vê que até para ele em alguns momentos a técnica não é fácil! E isso está relacionado a maneira como aprendemos a programar. No mesmo livro ele diz que TDD é extremamente natural para sua filha porque ele ensinou para ela a técnica enquanto a ensinava a programar.
Esse o conceito está errado. A técnica não é usar o código antes de ele existir pois se você usa o código antes de ele existir então já tem o código na sua cabeça e sem tem na sua cabeça é só criar o método e coloca-lo dentro e, desse modo, tanto faz se você cria o método de teste antes ou depois pois você já projetou toda a lógica e o teste acaba só sendo uma forma de garantir que aquilo que você projetou está correto! Sendo assim a premissa inicial do colega é valida pois o teste só serve para garantir que o que foi feito esta certo e eu posso ter um TDD sem testes!
Isso é natural porque estamos condicionados a pensar assim pois fomos ensinados assim! Sempre nós projetamos na nossa cabeça e depois implementamos só que TDD não é isso pois nesse caso o desenvolvimento não está sendo dirigido pelo teste e sim pela forma que achamos que aquilo deve funcionar!
Embora isso até pareca correto (e em alguns momentos podemos usar isso com práticas TDD) este não é o cerne da finalidade do teste. A ideia é que o teste ajude no projeto da lógica e, nesse caso, a lógica não está na sua cabeça. Você não usa a lógica antes, você projeta a lógica a partir do teste. Para ilustrar isso vou usar o mesmo exemplo da média acima e vou partir do pressuposto que nunca calculei uma média antes. Na minha lista de teste eu adicionei o seguinte: Calcular a média de 2 numeros.
Então o que faço primeiro é:
@Test
public void testaMedia()
int mediaExperada;
assertEquals(mediaExperada, media.resultado());
}
Ai eu penso, como calculo uma média (ou vou na wikipedia)? Eu lembro que uma media é a soma de um conjunto de números dividido pelo número de elementos da soma. Então eu faço:
@Test
public void testaMedia(){
int mediaExperada = Soma / numeroDeElemendoDaSoma;
assertEquals(mediaExperada, media.resultado());
}
Blz mas qual o número de elementos da soma? Bom nesse caso eu sei pelo que foi especificado na lista de teste que é dois então eu faço:
[code] @Test
public void testaMedia(){
int soma = elemento1 + elemento2;
int numeroDeElementos = 2;
int mediaExperada = soma / numeroDeElemendoDaSoma;
assertEquals(mediaExperada, media.resultado());
}
[/code]Eu olho para o código e só falta declarar os elementos então:
[code] @Test
public void testaMedia(){
int elemento1 = 10;
int elemento2 = 12;
int soma = elemento1 + elemento2;
int numeroDeElementos = 2;
int mediaExperada = soma / numeroDeElemendoDaSoma;
assertEquals(mediaExperada, media.resultado());
}
[/code]Esse foi um exemplo bem step by step do que é o “dirigido” por testes e que a finalidade fundamental do teste é ajudar ajudar a projetar a logica.
Desse modo o teste também faz com que se obtenha feedback do que foi implementado está certo e por consequência o acaba ajudando a garantir a qualidade porém essas não são as principais finalidades dele!
Claro que se eu sei a lógica eu não preciso fazer tão passo a passo e posso ir direto para a última implementação, mas, nesse caso, só estou preocupado em obter o feedback positivo e em garantir a qualidade e, embora isso faça parte de TDD, eu estou usando somente o “Desenvolvimento” e o “Teste” porém fica faltando o faltando o “Dirigido” ai!
Buscar somente o feedback e garantir a qualidade ocorre muito durante a pratica de TDD pois muitas vezes sabe-se como implementar algo (em outras ocasiões você vai ter tanta confiança em algo que não vai nem se dar ao trabalho de implementar um teste) e, embora essas ações não sejam as principais finalidades do teste não é errado faze-lo pois TDD não é um contrato fixo que diz que você obrigado a projetar a lógica usando o teste.
Isso está correto, mas ele não está relacionado ao número de passos e sim na confiança no que você projetou! Ele deve ser usado quando você tem duvidas sobre a logica que implementou (independente de ela ser simples ou complexa)! Se você tem dúvida sobre alguma coisa use triangulação.
Isso soa estranho pois se você usa TDD da maneira correta não deveria ter problemas com o código testado pois projetou o código a partir do teste sendo assim o problema estaria no seu teste!
Pela experiência que tenho quando se está tendo problemas com os testes o problema com certeza está no código mas é por você não está usando TDD da maneira correta!
Isso não quer dizer que as coisas não vão ficar estranhas quando se está usando TDD da maneira correta, pelo contrário, mas nesses casos você esta projetando com ajuda do teste então tem feedback antes de implementar a classe ou método!
Nesse momento você vê começa a se questionar se seus testes representam fielmente o dominio da aplicação! Pega a lista de testes revê cada um dos testes já implementados e começa a criar testes alternativos de modo a criar um modelo mais fidedigno e isso é muito legal pois você acaba por criar novos testes e a descartar testes antigos o que leva a uma grande refatoração no sistema para um modelo mais rico!
Eu já disse, não uso “TDD” e os projetos de testes aqui estão fechados a meses.
Eu sigo a filosofia use-first/create-later sem testes, isso me ajuda a terminar macro features sem ter implementado toda logica necessaria.
E já que o que eu aprendi não é TDD, vou procurar para ver se existe um nome ou então criar um eu mesmo
Eu não vi diferença no exemplo da media do que eu fiz para o que voce postou, o TDD ajuda a projetar, mas você não vai precisar ir na wikipedia para fazer algo que já sabe. Nesse caso acredito que voce esteja seguindo a propria arquitetura que já esperava.
E o fato de criar a logica no teste já deixa uma armadilha, se voce copia-la para dentro do método que quer testar, claro que ela vai ser testada com sucesso, mas é por que o teste só compara valores e não a logica em si.
Voce não vai fazer um projeto sem saber qual é o destino (as vezes podem faltar definições, mas isso é culpa do projeto e vai refletir na aplicação).
