O programador profissional precisa de testes unitários?

ViniGodoy wrote:

xandroalmeida wrote: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.

Há uns tempos atrás, li um artigo que questionava justamente essa afirmação. Veja bem, ele não era contra os testes unitários, e nem contra alterar a arquitetura. Mas o que ele questionava é até que ponto seria correto alterar a arquitetura para termos um JUnit?

Por exemplo, é prudente tornar um método que deveria ser privado "mais publico" só para testa-lo?

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.

Sei, e defendo, que a industria de software é muito diferente das industrias "fisicas". Mas vejam, em qualquer produto (televisão, carro, celular etc etc etc) tem pontos, as vezes circuitos inteiros, que servem apenas para testar o sistema. Então não vejo erro em alterarmos o software para ele ser testável.

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 684 Offline

rodrigoy wrote:
Se estou concentrando o teste na façade o teste é de integração, pois várias unidades estão sendo testadas em conjunto e o que eu quero com o teste é validar um objetivo do ator, e não um componente isolado. Prefiro fazer isso no código do que em artefatos fora dele. Esse é o ponto. É um teste de integração, no código e é TDD. TDD é um ciclo, é um método de se trabalhar, testes unitários e ferramentas só auxiliam nessa tarefa. Na TDD, a cada 3-5 minutos você tem um micro-requisito analisado, implementado e testado. O conjunto de micro-requisitos forma um requisito do usuário, como um caso de uso. Se alguém mandar um caso de uso aqui eu mando a classe de teste se alguém tiver mais alguma dúvida.

Entendi seu ponto... mas pra acrescentar diria que TDD compreende: suite de testes unitarios, integracao continua e propriedade coletiva de codigo.

rodrigoy wrote:
Com DSLs como o Phillip postou ou com o FIT dá pra fazer TDD com linguagem humana, aí passa a ser compreendido pelo stakeholder (o melhor dos mundos). Infelizmente em Java a DSL não é tão trivial, talvez em Groovy seja possível fazer algo parecido com o RSpec (nem sei se existe). BDD (entre outras coisas) é a evolução da TDD para vencer esse GAP e realmente a documentação de requisitos se tornar executável.

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.

This message was edited 1 time. Last update was at 03/03/2008 17:46:24

Lezinho wrote:

pcalcado wrote: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.

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 ?

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.

This message was edited 1 time. Last update was at 03/03/2008 17:46:10

cmoscoso wrote:
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.

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.

Virtual Machine Man Membro desde: 21/01/2004 14:12:54 Mensagens: 618 Offline

pcalcado wrote:

Lezinho wrote:

pcalcado wrote: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.

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 ?

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.

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.

cmoscoso wrote:E também acho que FIT ja nao pertence ao escopo de TDD e esta mais para definicao de requisitos.

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...

This message was edited 3 times. Last update was at 03/03/2008 18:32:29

xandroalmeida wrote:

ViniGodoy wrote:Por exemplo, é prudente tornar um método que deveria ser privado "mais publico" só para testa-lo?

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.

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!

microfilo wrote:Ainda tneho dificuldades em acreditar que um teste unitário possa servir como documento de requisitos. Alguém tem algum exemplo do mundo real?

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).

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 684 Offline

pcalcado wrote:
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.

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?

This message was edited 1 time. Last update was at 03/03/2008 19:53:03

s4nchez wrote:

cmoscoso wrote:E também acho que FIT ja nao pertence ao escopo de TDD e esta mais para definicao de requisitos.

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...

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...

http://jamesshore.com/Blog/Five-Ways-to-Misuse-Fit.html

http://www.extremeprogramming.org/map/project.html

cmoscoso wrote:Testes de aceitacao nao guiam desenvolvimento, e quem os escreve nao sou eu programador, mas o cliente.

1) Nao eh pq o cliente eh dono dos testes de aceitacao que ele tem que escreve-los
2) Nao eh pq o cliente eh dono dos testes de aceitacao que um programador nao pode encostar neles
3) Nao eh pq o cliente eh dono dos testes de aceitacao que eles nao guiam o desenvolvimento

cmoscoso wrote:Testes de aceitacao dizem se um caso de uso foi implementado (black-box).

Yeap, e exatamente por isso eles sao otimos pra guiar o meu desenvolvimento antes mesmo de eu comecar a mexer em codigo.

cmoscoso wrote:

pcalcado wrote:
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.

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?

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.

Virtual Machine Man Membro desde: 23/10/2007 10:08:29 Mensagens: 684 Offline

cv wrote:
Yeap, e exatamente por isso eles sao otimos pra guiar o meu desenvolvimento antes mesmo de eu comecar a mexer em codigo.

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).

cv wrote:
Sim - soh dar uma olhada nos exemplos de testes que o yoshi postou. Se um programador olhar pras assinaturas dos metodos e souber o que os testes estao tentando provar, ele tb entende os requisitos daquela unidade que esta sendo testada. Junta isso com uma ferramenta de cobertura e vc tb pode avaliar onde faltou teste ou onde fizeram gambiarras.

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

pcalcado wrote: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.

Tem alguma referencia mais concreta sobre a teste unitário poder testar qualquer unidade e não a menor unidade?

Notícias, artigos e o maior fórum brasileiro sobre Java