Os códigos que mais retornam dos testadores aqui na empresa, são dos programadores que NÃO fazem testes unitários.
[quote=Marcio Duran] :XD: A gerência tem foco no que possa já cumprir a primeira etapa do projeto, em vista do protótipo possa dar reflexos aparentes de funcionalidades, entre os projetista consultores na divisão de responsabilidades pela gestão de entrega desses requisitos ao ciclo de desenvolvimento projetado, entra ai a questão, o que é um modelo de produtividade,e se este sendo por interação(colaborado em a equipe em uma espécie de XP) ou um processo focado em modelo de fabrica de Software com exploração a metodologia RUP, test case a implementar, outros instrumentos a se considerar.
:thumbup: Existem outros fatores ao business core pelo tempo e aceitação, a fase 2 continuara, a gerência será a mesma, outra abordagem tecnologica mudou o rumo desse projeto.Acho que teste unitários vão de ponta a ponta ao projeto, mas previsões existem.
[/quote]
Tá parecendo aqueles programas geradores de texto enfeitado… :roll:
O programador profissional precisa de testes unitários? Você é um programador que vive isolado em um projeto, você faz tudo na sua casa e depois diz que já terminou tudo.
Qual é a sua tese ?
Tá parecendo aqueles programas geradores de texto enfeitado… :roll: [/quote]
É só você ignorar que ele desaparece 
Tiro e queda.
Acho que foi uma tradução mal feita inglês-português.
Não deixa de ser um gerador de texto desconexo.
[quote=Marcio Duran]
O programador profissional precisa de testes unitários? Você é um programador que vive isolado em um projeto, você faz tudo na sua casa e depois diz que já terminou tudo.
Qual é a sua tese ?[/quote]
Hein?!?!
Alguém entendeu a resposta?
[quote=Paulo Silveira]
O que você acha dos testes unitários? Esta prática é adotada na sua empresa? Quais os resultados que você obteve? [/quote]
Estratégia TDD é uma importante parte integrante do “ciclo ágil de um dia”, o trabalho do desenvolvedor. Vejo TDD mais como requisitos, design e documentação do que como realmente testes. Lembre-se que nas abordagens ágeis a especificação fora do código é levíssima. Por isso TDD é imprescindível para equipes XP: documentar.
Antigamente levava os testes unitários a lá UP (não exatamente o trabalho de "pegar um requisito, fazer um teste, fazer falhar, fazer passar, chegar a um pedacinho de software funcionando). Nos meus últimos projetos a abordagem TDD tem sido mais disciplinada. Porém, é um misto de teste unitário e teste de integração mesclado no código.
Um documento de arquitetura, user stories simples, DDD e TDD tem sido suficientes para garantir qualidade e documentação da maioria dos projetos. Vou escrever a respeito disso na MJ que sai em Maio!
Yoshi, ja deu uma brincada com JBehave e RSpec? O que tem achado?
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…
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)
Valeu pelos links, mas nao entendi exatamente onde esta a ‘polemica’
Isso por si não garante que o requisito\necessidade do usuário foi implementada com sucesso.
Que cenários?
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.
[quote=peczenyj]
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.[/quote]
Concordo. Só que o teste unitário não garante que a aplicação funciona.
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.
@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.
Então concorda que um teste unitário não serve como documento de requisitos?
Concordo.
Faz um certo sentido, afinal, o teste diz como o sistema deve funcionar, assim como o requisito.
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.
Nesse ponto vc pode fazer testes de integração de código. Vc faria com um framework de teste como o JUnit também.
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.
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.
É 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.
[quote=cv] 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…
[/quote]
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.
[quote=microfilo]
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.[/quote]
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?
public class CadastrarGradeCurricularTest {
public void asRestricoesDeHorarioDoProfessorDevemSerRespeitadas() {}
public void umProfessorNaoPodeEstarEmDuasAulasAoMesmoTempo() {}
public void umaSalaNaoPodeSerOcupadaPorDuasAulasAoMesmoTempo() {}
}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)