O programador profissional precisa de testes unitários?

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 unitarios servem como documento de requisitos pra unidade que estao testando, por isso vc provavelmente nao vai ter um teste unitario que sirva pra mostrar pro stakeholder. De qualquer forma, a funcao deles em documentar o design da aplicacao eh imprescindivel, uma vez que eh a ferramenta atraves da qual desenvolvedores do projeto comunicam o que estavam tentando fazer com o codigo naquela hora.

Ja vi muitos casos onde os testes de integracao/aceitacao servem como "documento de requisitos", mas no fim das contas, o que se chama de "documento de requisitos" na maior parte dos projetos nao-ageis que eu vi ate hoje nao passa muito de uma pilha de docs e pdfs e diagramas que ninguem atualiza depois do segundo mes, anyway...

Thread.start() Membro desde: 27/03/2006 08:33:20 Mensagens: 33 Offline

Realmente, neste início de ano tem muita gente falando, escrevendo e debatendo sobre testes, questionando como os testes estão sendo feitos, e propondo diferentes abordagens e melhorias.

Além do Infoq, que tem publicado muito material sobre testes ultimamente, segue alguns posts que li recentemente sobre este interessante e polêmico assunto:
Patrick Kua 1 , Patrick Kua 2 , Uncle Bob , Zack Bowling , Howard Lewis Ship e Nic Williams (Dr. Nic)

mfb wrote:sobre este interessante e polêmico assunto

Valeu pelos links, mas nao entendi exatamente onde esta a 'polemica'

peczenyj wrote:
Os testes unitários certificam que uma unidade atômica de código foi testada e seu comportamento esta dentro do esperado.

Isso por si não garante que o requisito\necessidade do usuário foi implementada com sucesso.

peczenyj wrote:
Considerando que vc pode escrever um teste antes de implementar o código em si, vc consegue testar aquele código sem que a gui esteja pronta, por exemplo, e pode explorar cenarios que a gui nem conseguiria chegar.

Que cenários?

peczenyj wrote:
Sem falar que vc pode descobrir com muita rapidez que uma determinada modificação quebrou os testes unitários (antes de integrar o código). Imagina descobrir um dia depois que aquela modificaçãozinha quebrou a aplicação? Mó stress né? Podia ser evitado né?

Então, aí que que tá, os testes unitários vão acusar erro se a sua unidade atômica de código tiver algum erro... as vezes o erro esta na "ligação" entre duas classes.

peczenyj wrote:
Só posso imaginar que um programador que não testa o seu código não tem meios de garantir o real comportamento da sua obra (uml não garante, documento do word não garante), terminando em bugs cujo custo de testar, encontrar e corrigir não são brincadeira.

Concordo. Só que o teste unitário não garante que a aplicação funciona.

cv wrote:Yoshi, ja deu uma brincada com JBehave e RSpec? O que tem achado?

Pois é, o Shoes já tinha comentado comigo. O projeto que estou hoje uso o TestNG pois é Seam, mas EJB3 é bem frustrante com relação a TDD:

http://www.guj.com.br/posts/list/81757.java

O JBehave ainda não usei. Estou com um novo pet project que vou abrir o fonte para realmente mostrar como TDD pode ser documentação executável. Vou fazer bunitinho e aproximar do BDD. Pode ter que incorpore o JBehave (depois colaboro com vocês).

Só o Test::Unit já rula. RSpec é muito elegante, mas ainda estou engatinhando no Ruby/Rails.

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?

@Test
    @ExpectedExceptions (DomainException.class)
    public void umaSalaNaoPodeSerOcupadaPorDuasAulasAoMesmoTempo() {
    	
        // Registra Hugo em Contabilidade 1 às 13:00 de quarta-feira, sala 107
        Carreira administracao = em.find(Carreira.class, new Long(1));
        Professor hugo = em.find(Professor.class, new Long(4003));
        Materia contabilidade1 = em.find(Materia.class, new Long (3005));
        Horario quartaTrezeHoras = em.find(Horario.class, new Long(2011));
        String sala107 = "107";

GradeCurricularItem gcii = new GradeCurricularItem();
        gcii.setCarreira(administracao);
        gcii.setProfessor(hugo);
        gcii.setMateria(contabilidade1);
        gcii.setHorario(quartaTrezeHoras);
        gcii.setSala(sala107);
        
        gradeCurricularRepository.add(gcii);
        
        // Tenta registrar Milton José em Economia 2 às 13:00 de quarta-feira, sala 107
        Professor milton = em.find(Professor.class, new Long(4002));
        Materia economia2 = em.find(Materia.class, new Long(3002));
        
        GradeCurricularItem gci = new GradeCurricularItem();
        gci.setCarreira(administracao);
        gci.setProfessor(milton);
        gci.setMateria(economia2);
        gci.setHorario(quartaTrezeHoras);
        gci.setSala(sala107);
        
        gradeCurricularRepository.add(gci); //Isso deve lançar DomainException
    }
}

Lembre-se, não confunda documento de requisitos com documentação de requisitos. Lembre-se, quem vai manter a aplicação é um programador e não um analista de negócios estúpido que não sabe programar (bem, a maioria deles também não sabe documentar requisitos). Avoid too many layers também nos artefatos de projeto.

cv wrote:
Testes unitarios servem como documento de requisitos pra unidade que estao testando, por isso vc provavelmente nao vai ter um teste unitario que sirva pra mostrar pro stakeholder.

Então concorda que um teste unitário não serve como documento de requisitos?

cv wrote:
De qualquer forma, a funcao deles em documentar o design da aplicacao eh imprescindivel, uma vez que eh a ferramenta atraves da qual desenvolvedores do projeto comunicam o que estavam tentando fazer com o codigo naquela hora.

Concordo.

cv wrote:
Ja vi muitos casos onde os testes de integracao/aceitacao servem como "documento de requisitos"

Faz um certo sentido, afinal, o teste diz como o sistema deve funcionar, assim como o requisito.

cv wrote:
Mas no fim das contas, o que se chama de "documento de requisitos" na maior parte dos projetos nao-ageis que eu vi ate hoje nao passa muito de uma pilha de docs e pdfs e diagramas que ninguem atualiza depois do segundo mes, anyway...

E nos seus projetos ágeis? Os requisitos simplesmente se limitam aos testes e a um monte de post-its colados na parede ou num quadro?

Eu acredito que o seu requisito não precisa ser documentado da forma "tradicional", use-case, com diagramas de caso de uso e etc, mostrando todos os atores e etc. Mas acho que um documento eletrônico, descrevendo o que o sistema deve fazer, numa linguagem "humana", isso eu acho que deve ter! Também não precisa ser elaborado totalmente no começo do projeto, pode ser algo que vai sendo detalhado conforme o andamento do projeto.

Que cenários um teste de Gui não chega?

Exceptions que dependam de banco de dados ou outra parte do sistema, por exemplo.
Rotinas assincronas, recebimento de email, etc.

as vezes o erro esta na "ligação" entre duas classes.

Nesse ponto vc pode fazer testes de integração de código. Vc faria com um framework de teste como o JUnit também.

rodrigoy wrote:
@Test @ExpectedExceptions (DomainException.class) public void umaSalaNaoPodeSerOcupadaPorDuasAulasAoMesmoTempo() { // Registra Hugo em Contabilidade 1 às 13:00 de quarta-feira, sala 107 Carreira administracao = em.find(Carreira.class, new Long(1)); Professor hugo = em.find(Professor.class, new Long(4003)); Materia contabilidade1 = em.find(Materia.class, new Long (3005)); Horario quartaTrezeHoras = em.find(Horario.class, new Long(2011)); String sala107 = "107"; GradeCurricularItem gcii = new GradeCurricularItem(); gcii.setCarreira(administracao); gcii.setProfessor(hugo); gcii.setMateria(contabilidade1); gcii.setHorario(quartaTrezeHoras); gcii.setSala(sala107); gradeCurricularRepository.add(gcii); // Tenta registrar Milton José em Economia 2 às 13:00 de quarta-feira, sala 107 Professor milton = em.find(Professor.class, new Long(4002)); Materia economia2 = em.find(Materia.class, new Long(3002)); GradeCurricularItem gci = new GradeCurricularItem(); gci.setCarreira(administracao); gci.setProfessor(milton); gci.setMateria(economia2); gci.setHorario(quartaTrezeHoras); gci.setSala(sala107); gradeCurricularRepository.add(gci); //Isso deve lançar DomainException } }

Lembre-se, não confunda documento de requisitos com documentação de requisitos. Lembre-se, quem vai manter a aplicação é um programador e não um analista de negócios estúpido que não sabe programar (bem, a maioria deles também não sabe documentar requisitos). Avoid too many layers também nos artefatos de projeto.

Você vai me desculpar, mas no que isso documenta um requisito, oras?
O requisito dum sistema pode ser implementado de N maneiras, pode ser procedureal, OO, usando DDD. DomainException? O que isso tem haver com o requisito? Referencia a um EntityManager? Não, não, isso pra mim diz a respeito de como o sistema foi implementado e não como o sistema deve ser implementado. E como o CV disse, não é algo que vai ser apresentado aos stackholders.

peczenyj wrote:
Exceptions que dependam de banco de dados ou outra parte do sistema, por exemplo.
Rotinas assincronas, recebimento de email, etc.

Hum, é verdade, mas dependendo da ferramenta que você esa utilizando, você pode fazer o script de teste da GUI fazer essas verificações também.

peczenyj wrote:
Nesse ponto vc pode fazer testes de integração de código. Vc faria com um framework de teste como o JUnit também.

É verdade, mas hoje existem ferramentas bem amigáveis para fazer teste automatizado baseado em GUI. As vezes fica até mais fácil que fazer com um JUnit da vida.

cv wrote: Testes unitarios servem como documento de requisitos pra unidade que estao testando, por isso vc provavelmente nao vai ter um teste unitario que sirva pra mostrar pro stakeholder...

Lembrando que essa unidade pode até ser um "caso de uso". Digo isso porque se a sua camada de apresentação for bem "declarativa" e não tiver código procedural você pode concentrar classes de teste nas suas façades e o efeito para o projeto pode ser o mesmo de procedimentos de teste manuais derivados de casos de teste (à lá RUP).

TDD não é só teste unitário. Quando escrevo classes de teste concentradas nas façades (ou controllers) sinto como se estivesse fazendo o teste na tela mesmo. O bom é que a automação é mais simples. De qualquer forma, se precisamos testar comportamentos de tela temos o Selenium para nos ajudar.

microfilo wrote:
Você vai me desculpar, mas no que isso documenta um requisito, oras?
O requisito dum sistema pode ser implementado de N maneiras, pode ser procedureal, OO, usando DDD. DomainException? O que isso tem haver com o requisito? Referencia a um EntityManager? Não, não, isso pra mim diz a respeito de como o sistema foi implementado e não como o sistema deve ser implementado. E como o CV disse, não é algo que vai ser apresentado aos stackholders.

Foi um exemplinho rápido que peguei aqui, mas mesmo assim acho que você não prestou atenção. Sem ofensas, vc deve ser fã de um "Unified Approach" para requisitos. Certo?

Quando estou "capturando" e "documentando" requisitos crio uma classe com implementações vazias como a acima talvez com um Javadoc mais elaborado se necessário (pode até ter um texto de caso de uso). Depois, crio o código executável (como o que mandei anteriormente) lentamente, fazendo o ciclo red-green-done.

Poderia estar num documento Word? É uma alternativa, mas a tendência dele à desatualização é grande, e documentação fora do código ajuda muito pouco na manutenção. Todos os requisitos estão alí? Não, os requisitos da visão estática do sistema (os dados) não estão. Eles podem estar no código nas minhas entities ou num diagrama de classe. Outros requisitos não funcionais, conformidade, padrões estão num especificação suplementar. Todos testes estão cobertos? Não, mas creio que grande parte sim. Podem existir testes de carga, de aceitação e etc...

O cliente ou usuário não quer ver documentos de requisitos. Ele quer ver requisitos implementados (resolvendo problemas). Só para constar, pelo que me lembro nenhuma metodologia séria diz que deve exisitir qualquer validação de requisitos com o usuário com algo que não seja software funcionando, então, é questionável que especificações detalhadas de requisitos estejam numa linguagem que o usuário entenda.

(sei que o que disse aqui contradiz muito a visão que "analistas de negócio" têm por aí sobre o assunto)

This message was edited 1 time. Last update was at 02/03/2008 23:36:05

rodrigoy wrote:
Lembrando que essa unidade pode até ser um "caso de uso". Digo isso porque se a sua camada de apresentação for bem "declarativa" e não tiver código procedural você pode concentrar classes de teste nas suas façades e o efeito para o projeto pode ser o mesmo de procedimentos de teste manuais derivados de casos de teste (à lá RUP).

Peraí que você esta me confundindo, Rodrigo, O teste unitário é para testar a menor unidade do meu código, e no caso de Java é o a classe, correto?
Então como você pode dizer que essa unidade pode ser um "caso de uso"?

rodrigoy wrote:
Digo isso porque se a sua camada de apresentação for bem "declarativa" e não tiver código procedural você pode concentrar classes de teste nas suas façades e o efeito para o projeto pode ser o mesmo de procedimentos de teste manuais derivados de casos de teste (à lá RUP).

Mas aí ja não é um teste unitário, ou a sua unidade não é caso de uso.

rodrigoy wrote:
TDD não é só teste unitário.

Eu estava me referindo a testes unitários e não a TDD em geral.

rodrigoy wrote:
Quando escrevo classes de teste concentradas nas façades (ou controllers) sinto como se estivesse fazendo o teste na tela mesmo.

Não tem o mesmo efeito que você fazer o teste na tela. Se você vai fazer ou não, aí depende do nível de QA que você quer para o seu projeto\empresa.

rodrigoy wrote:
O bom é que a automação é mais simples. De qualquer forma, se precisamos testar comportamentos de tela temos o Selenium para nos ajudar.

Eu acho as ferramentas que automatizam o teste nas telas não são tão complicadas assim. Se bobear é quase tão simples como fazer um teste integrado na façade.

rodrigoy wrote:
Foi um exemplinho rápido que peguei aqui, mas mesmo assim acho que você não prestou atenção. Sem ofensas, vc deve ser fã de um "Unified Approach" para requisitos. Certo?

Não, não... imagina, não sou um fã de um "Unified Approach", já trabalhei assi, e particularmente gosto muito de metodos ágeis e tento aplicar ao máximo no meu dia-a-dia - infelizmente as vezes não consigo por fatores externos a mim, mas no que depender de mim, eu uso agile, ou melhor, a minha visão de agile. É que eu só sou chato em fóruns, gosto de testar os argumentos apontados pela galera até o fim, estressar todas os fatores contra mesmo, as vezes eu vejo um post e tento pensar em todas as argumentações contra o que foi postado poderiam ser levantadas e faço um quote do post com elas. Acho que todos saem ganhando com isso quando há respeito.

E até me ajuda quando eu precisar defender os principios do Agile assim como você e o CV estão fazendo muito bem.

Nesse caso em particular dos testes serem documentação de requisitos eu não concordo com você, embora eu ache que faça um certo sentido o que você esta querendo dizer.

rodrigoy wrote:
Poderia estar num documento Word? É uma alternativa, mas a tendência dele à desatualização é grande, e documentação fora do código ajuda muito pouco na manutenção. Todos os requisitos estão alí? Não, os requisitos da visão estática do sistema (os dados) não estão. Eles podem estar no código nas minhas entities ou num diagrama de classe. Outros requisitos não funcionais, conformidade, padrões estão num especificação suplementar. Todos testes estão cobertos? Não, mas creio que grande parte sim. Podem existir testes de carga, de aceitação e etc...

O requisito deve dizer como o que o software deve fazer e como ele deve se comportar não vejo como, por exemplo, um diagrama de classes pode ajudar.
Vcoê pode conseguir essas informações juntando todos esses insumos aí que você mencionou, mas acho que aí você acaba perdendo a visão do todo.
Quanto a ficar destualizado, o teste pode ficar destualizado também, não? E em todo o caso, existem ferramentas que fazem rastreabilidade entre requisito e outros artefatos, como código por exemplo. Isso pode ajudar a equipe a manter todos os artefatos atualizados.

rodrigoy wrote:
O cliente ou usuário não quer ver documentos de requisitos. Ele quer ver requisitos implementados (resolvendo problemas). Só para constar, pelo que me lembro nenhuma metodologia séria diz que deve exisitir qualquer validação de requisitos com o usuário com algo que não seja software funcionando, então, é questionável que especificações detalhadas de requisitos estejam numa linguagem que o usuário entenda.

(sei que o que disse aqui contradiz muito a visão que "analistas de negócio" têm por aí sobre o assunto)

Pois é... acho que aí depende muito do cenário Rodrigo... sei lá, as vezes o próprio cliente exige isso, as vezes isso te salva-guarda na hora de uma negociação ou problema...

microfilo wrote:
Peraí que você esta me confundindo, Rodrigo, O teste unitário é para testar a menor unidade do meu código, e no caso de Java é o a classe, correto?
Então como você pode dizer que essa unidade pode ser um "caso de uso"?

Pra dentro da minha façade tem um monte de objetos colaborando entre sí, porém, aquilo que realmente interessa para esse tipo de teste é o que oferece valor para o Ator. É um teste no código concentrado no objetivo do ator (caso de uso).

É possivel até usar um teste em código que valida e documenta um processo de negócio que envolva vários casos de uso (como exemplo posso encadear uma Suite do TestNG com vários testes concentrados nas façades).

microfilo wrote:
Eu estava me referindo a testes unitários e não a TDD em geral.

O post todo é sobre TDD em geral.

microfilo wrote:
Eu acho as ferramentas que automatizam o teste nas telas não são tão complicadas assim. Se bobear é quase tão simples como fazer um teste integrado na façade.

Selenium ajuda bastante, mas ainda é ruim de manter e assertar (acho que essa palavra não existe, mas para uma madrugada de domingo pra segunda está muito bom). Para falar a verdade o problema maior é que numa aplicação Java a infra-estrutura para as coisas funcionarem dificulta enormemente o debug (o servidor demora quase 1 minuto pra subir e o turnaround é brochante). Não dá pra perder tempo com isso e você precisa dessa infra para automatizar o teste na tela.

This message was edited 1 time. Last update was at 03/03/2008 00:26:57

rodrigoy wrote:
Pra dentro da minha façade tem um monte de objetos colaborando entre sí, porém, aquilo que realmente interessa para esse tipo de teste é o que oferece valor para o Ator. É um teste no código concentrado no objetivo do ator (caso de uso).

É possivel até usar um teste em código que valida e documenta um processo de negócio que envolva vários casos de uso (como exemplo posso encadear uma Suite do TestNG com vários testes concentrados nas façades).

Peraí, a alguns posts atrás você falou que a unidade do teste unitário poderia ser o "caso de uso" (você até colocou entre áspas, se não me engano).
Isso é errado, não tem o que discutir:

http://en.wikipedia.org/wiki/Unit_testing wrote:
In computer programming, unit testing is a procedure used to validate that individual units of source code are working properly. A unit is the smallest testable part of an application. In procedural programming a unit may be an individual program, function, procedure, etc., while in object-oriented programming, the smallest unit is a method; which may belong to a base/super class, abstract class or derived/child class.

Case caso de uso? acho que você esta misturando as conversas

rodrigoy wrote:
O post todo é sobre TDD em geral.

Título do post wrote:
Re:O programador profissional precisa de testes unitários?

De qualquer forma eu estava questionando:
1) A possibilidade de usar teste unitário como documentação dos requisitos.
2) A possibilidade de usar ferramentas que automatizam testes baseadas em GUI.

rodrigoy wrote:
Selenium ajuda bastante, mas ainda é ruim de manter e assertar (acho que essa palavra não existe, mas para uma madrugada de domingo pra segunda está muito bom).

Não conheço selenium... só conheço silktest (por que será?) e não tenho dificuldades em assertar. Não sei se o selenium seria tão dificil assim, eu acho que não.

rodrigoy wrote:
Para falar a verdade o problema maior é que numa aplicação Java a infra-estrutura para as coisas funcionarem dificulta enormemente o debug (o servidor demora quase 1 minuto pra subir e o turnaround é brochante). Não dá pra perder tempo com isso e você precisa dessa infra para automatizar o teste na tela.

Mas você precisa ficar rodando o teste o tempo todo?
E olhe, eu não estou dizendo que você deve fazer teste em GUI em detrimento a testes unitários.

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