Entendi seu ponto… mas pra acrescentar diria que TDD compreende: suite de testes unitarios, integracao continua e propriedade coletiva de codigo.
A sugestao que lhe dei nao usa DSLs. E também acho que FIT ja nao pertence ao escopo de TDD e esta mais para definicao de requisitos.
Phillip, não entendi algo na sua afirmação.
Até compreendo, via mocks, o teste sobre componentes. Mas quanto a processos fiquei um pouco confuso.
Nestes casos ( processos) o teste aplicado não deveria ser de “integração” ao invés de unitários ?
[/quote]
Em sistemas natios UNIX geralmente uma aplicação se divide em processos, como você em os processos do apache ou do sendmail rodando. Cada proceso é um binário e geralmente eles se comunicam por trocas de sinais, pipes, memória compartilhada ou outro mecanismo de IPC. Cada processo 'um componente e pode ser testado em isolamento.
[quote=cmoscoso]
A sugestao que lhe dei nao usa DSLs. E também acho que FIT ja nao pertence ao escopo de TDD e esta mais para definicao de requisitos.[/quote]
Eu sempre usei Fit com itnesse e ele tem uma DSL gráfica, mas o que ele faz é teste funcional e como falei testes funcionais expressam requisitos funcionais.
Acho que o grande problema de TDD hoje é que as pessoas não sabem testar software. É muito comum encontrar um bando de testes que fazeme xatamente a mesma coisa, as pessoas não possuem a técnica necessária para escrever testes eficientes.
Bom, testes não eficientes (mas eficazes) são melhores que nenhum, mas existe uma grande possibilidade de evolução.
Phillip, não entendi algo na sua afirmação.
Até compreendo, via mocks, o teste sobre componentes. Mas quanto a processos fiquei um pouco confuso.
Nestes casos ( processos) o teste aplicado não deveria ser de “integração” ao invés de unitários ?
[/quote]
Em sistemas natios UNIX geralmente uma aplicação se divide em processos, como você em os processos do apache ou do sendmail rodando. Cada proceso é um binário e geralmente eles se comunicam por trocas de sinais, pipes, memória compartilhada ou outro mecanismo de IPC. Cada processo 'um componente e pode ser testado em isolamento.[/quote]
Ok, sabia que era alguma interpretação equivocada. Pensei que você falava sobre processos de negócio. Neste caso, como um processo envolve vários componentes, um teste mais coerente sobre o processo seria a “Integração”, e não a unidade.
Da onde você tirou isso? Experimente escrever seus testes de aceitação em Fitnesse e você vai ver que ele também pode guiar seu desenvolvimento, e provavelmente vai complementar muito bem os testes de unidade…
Não estou entrando no mérito se é certo ou errado, mas o fato de que testar alguma coisa que não esta preparada para ser testável é muito dificil,na maioria das vezes impossível.[/quote]
Perfeito! E na minha opinião, esse é o grande valor do teste unitário. Só pelo fato de ele te fazer pensar sobre o design das suas classes, já vale a pena. Essa deveria ser a principal motivação ao se fazer um teste unitário. Código testável é código fracamente acoplado, bem encapsulado e isolável.
Todo o resto (documentação da unidade sendo testada, regressão, etc…) é lucro!
Testes unitários documentam os requisitos para a unidade sendo testada. Isso é diferente de documentar a funcionalidade ou o requisito a ser implementado. Para isso os testes funcionais.
Pense no teste unitário substituindo aquele enorme javadoc que você estava escrevendo para a sua classe para que os outros entendam o uso dela. A vantagem do teste unitário é ser executável! Agrega mais valor.
Bom, como você pediu, alguns exemplos (já citados pelo Phillip).
Essa DSL foi criado por fixtures customizadas certo?
Curiosidade: Pq usou os dois projetos juntos? Voce tem preferencia por algum dois dois, caso sim, poderia dizer pq?
Experimente escrever seus testes de aceitação em Fitnesse e você vai ver que ele também pode guiar seu desenvolvimento, e provavelmente vai complementar muito bem os testes de unidade…[/quote]
S4nchez,
Testes de aceitacao nao guiam desenvolvimento, e quem os escreve nao sou eu programador, mas o cliente.
Testes de aceitacao dizem se um caso de uso foi implementado (black-box).
Testes de aceitacao complementam sim testes unitarios, mas lembra daquela historia de ferramenta certa para um certo problema, pois é disso que estou falando…
Yeap, e exatamente por isso eles sao otimos pra guiar o meu desenvolvimento antes mesmo de eu comecar a mexer em codigo.
[quote=cmoscoso][quote=pcalcado]
Eu sempre usei Fit com Fitnesse e ele tem uma DSL gráfica, mas o que ele faz é teste funcional e como falei testes funcionais expressam requisitos funcionais.
[/quote]
Essa DSL foi criado por fixtures customizadas certo?
Curiosidade: Pq usou os dois projetos juntos? Voce tem preferencia por algum dois dois, caso sim, poderia dizer pq?[/quote]
Não, a DSL do Fitnesse, que vem com ele, tabelas e valores.
O Fitnesse oferece uma interface wiki, é bem razoável. Na verdade eu tô meio de saco cheio do Fit como um todo, mas quando preciso dele o Fitnesse sempre tá no pacote.
Eles também estão inclusos no seu ciclo red-green-refactor?
De certa forma sim, mas geralmente servem apenas como guia pra saber quando eu terminei de implementar a funcionalidade (e se eu deveria considerar a entrega).
Certo, eu tenho a visão dos requisitos daquela unidade sendo testada, e da visão do todo? Dos requisitos como um todo?
É, não adianta, acho que não vou me convencer enquanto não participar em um (raro) projeto que utiliza essa técnica 
[quote=pcalcado]1) Testes unitários documentam aquela unidade. A contrário do que a wikipedia diz você não está preso à classes ou funções, pode testar unitariamente um componente ou processo do seu sistema. Na verdade a maioria dos testes unitários tradicionais fazem isso.
[/quote]
Tem alguma referencia mais concreta sobre a teste unitário poder testar qualquer unidade e não a menor unidade?
“O que, você não tem capacidade para me entregar os dois?” 
Mas peraí, o cara tem que ser esperto e rodar o tempo todo só os testes que rodam mais rapidamente né, ou seja, os unitários! Não vai rodar o teste que sobe o JBoss cheio de EJBs e mapeamentos JPA!
O cliente me fala “o pedido de venda tem que ter um campo de observação”. Eu colocaria isso num requisito. Se eu vou guardar esse pedido em XML, num banco relacional, num banco OO, num papel de pão, não importa para o requisito em si.
Não é incomum o pessoal não atualizar as classes de testes - por pressões de prazo, alteram direto o código de produção e boa. Já vi isso acontecer com meus proprios olhos - inclusive removeram os testes da build pois estava atrapalhando, não serviam para nada, pois alguns nem compilavam. Acho que esse problema de não replicar a alteração em todos os artefatos não é resolvido transformando requisito em teste.
Sim… já vi utilizarem isso. A quantidade gasta em ferramentas depende do tamanho da equipe. Muita gente não se importa de investir alto em ferramentas pagas que resolvam o seu problema.
É fácil colocar teste de aceitação pra fora do TDD: são difíceis de se extrair, escrever, automatizar e manter. A questão é que os critérios de aceitação definidos com o cliente deveriam ser o guia principal para o desenvolvimento. É a maneira mais simples de verificar que um requisito foi implementado como esperado.
O problema é diferente mesmo. O que eu não entendo é essa tentativa de limitar TDD apenas a testes de unidade, se você pode obter muitos dos seus benefícios se aplicá-lo para outros testes…
Pra isso que serve integracao continua.
Pra isso que serve gerencia de projeto.
Pra isso que serve gerencia de configuracao.
Pra isso que serve vodka.
Pra isso que serve violencia.
Pra isso que serve integracao continua, de novo.
Nao? :mrgreen:
Eu escrevi minha opiniao sobre isso na pagina anterior:
Nao é pq é facil mas pq faz mais sentido pra mim. 
Acho que apenas estamos falando de “guiar desenvolvimento” em niveis diferentes. Eu nao tenho testes de aceitacao executando na maquina do desenvolvedor, mas sim no servidor de build. A integração continua é o ponto de intersecao entre TDD e os testes funcionais.
TDD compreende: 1) Escreva um teste que falhe 2) Faça o teste passar 3) Refatore 4) Volte para passo 1.
Se você faz TDD somente com teste unitário isto não significa que você mudou a definição de TDD.
[quote=xandroalmeida]Mas para isso o sistema deve ser coberto 100% por testes unitários e para isso o sistema deve nascer com testes unitários. É muito difícil você implementar teste em um sistema já existente. Mesmo porque para que um sistema seja bem testável sua arquitetura deve permitir isso.
[/quote]
Concordo !!!
Outra coisa que não entendo nesse Fórum, é estão discutindo mesmo, é que técnica o programador deve utilizar, em minha visão isso foge extremamente do contexto que envolve mesmo todo um cenário a ser considerado.
Bom até parece que o programador é uma espécie de um acumulador de papéis para tudo que é solução.