O programador profissional precisa de testes unitários?

Concordo com o Bob na teoria, e acho que esforcos nao devem ser poupados na medida do que eh pratico pra se automatizar todos os testes possiveis. O problema eh quando nao eh pratico automatizar alguns deles, ou quando rodar todos os testes torna sua integracao continua nao tao continua assim. Fora isso, 100% de acordo.

Impreterivelmente, sim. ThoghtWorks rula

Otimos. O design das aplicacoes eh assustadoramente melhor, e todo tipo de metrica que a gente ja passou nos projetos eh melhor de maneiras significativas (e a TW lancou um whitepaper sobre essas metricas que eu nao estou conseguindo achar agora por estar razoavelmente bebado/cansado/sem saco).

Estou brincando com Ruby e não sei se é falta de experiência minha com a linguagem ou realmente Ruby e Testes Unitários nasceram um para o outro. Minha impressão é que em Ruby vc realmente pode quebrar tudo mudando uma linha, mesmo que vc saiba exatamente o que está fazendo, pois sua característica dinâmica vai de encontro a maior robustês de uma linguagem estática (compile-typed) como Java.

Some-se a isso também a robustês das IDE Java, que te permite um excelente controle do big picture, call hierarchy, etc.

Em todas as empresas que trabalhei, testes unitários eram encorajados mas não exigidos. Vc acaba tendo que escolher entre um controle maior sobre o que vai para producão ou um ambiente mais dinâmico onde as pessoas devem se responsabilizar pelo seu código (tendo ou não testes unitários). Um controle de releases é fundamental, já que na descoberta de um eventual bug o código deve ser rollbackeado imediatamente para a última versão que funcionava.

Achar que um sistema com testes não terá bugs é tão errado quanto achar que um sistema sem testes não terá bugs. As chances de um programa com testes ter menos bugs do que um programa sem testes é obivamente MAIOR. Mas o quanto MAIOR vai depender de um monte de coisas.

Isso depende da característica da empresa. Do mesmo jeito que existe esquerda e direita, RUP e XP, Java e Ruby, etc. existem empresas e projetos que um controle total e testes totais serão exigidos e outras onde outras coisas serão mais valorizadas. Depende do seu time, do tamanho da sua equipe, do estágio do seu sistema, qualidade do código e por aí vai…

Numa empresa onde o sistema não possui testes unitários, vc precisa saber exatamente o que está fazendo, se possível executar outros tipos de testes antes de colocar o sistema em produção. Se esse esquema não está dando certo, então há duas opções: contrata-se outro profissional ou se a primeira opção já foi tentada muitas vezes sem resultado deve-se parar tudo para refazer o sistema ou adicionar testes unitários em tudo. Código spagetti sem testes modificado pelo o autor ou pior ainda por outra pessoa é realmente receita para sérios problemas (bugs).

Uma consultoria desenvolvendo um sistema para uma empresa cliente, só tem a ganhar com testes unitários. Primeiro gastará mais horas, segundo entregará um produto com seguro. Qualquer cliente sensato não vai se incomodar de pagar um pouco mais para ter testes unitários, e todos ficarão felizes.

Como vemos, cada caso um caso. Cada situação uma situação. Isso vale pra ambas as partes da discussão sobre testes: “Quem trabalha muito com um martelo terá a tendênca de achar que todo problema é prego.” Isso é fato. O que não se deve é sair martelando a cabeça de todo mundo.

Apenas minha opinião pessoal…

com certeza isso é fato, o problema é aqui existe empresas que infelizmente não fazem uma gerência correta do projeto(se é que podemos denominar isso de Empresa, ou aquilo de gerentes de projeto) e precisa de 1000 linhas pra antes de ontem, ai não tem jeito vai umas linhas sem teste :lol: e depois vai na correção :lol:

O que você acha dos testes unitários? Esta prática é adotada na sua empresa? Quais os resultados que você obteve?

hoje sim, estou realizando constantemente testes unitários e o resultado é incrível, projeto fluindo e cliente satisfeito :!:

Onde eu trabalho, existem certos trechos que fazem interface com um hardware em que os custos para se produzir um mock foram realmente impeditivos.

Especialmente pq um bom mock teria que simular várias das situações de concorrência, parse de diversos tipos de mensagem, etc.

Em todos os outros trechos, há testes unitários.

Onde eu trabalho há uma série de coisas que precisamos mudar, dentre elas, a falta de testes unitários.

Mas estamos prestes a marcar reuniões para analisar a qualidade dos softwares produzidos por nós, e eu pretendo enfatizar, dentre outras coisas, a importância dos testes unitários pra nós :mrgreen:

Eu nao sei se eu consigo descrever exatamente o quanto este argumento esta errado, saoj. Mas eu quero ver (e pago bem!) voce provar pra mim que um time de desenvolvedores com boa experiencia e um ambiente sem nenhum fator a se considerar um risco ao projeto demora mais pra entregar com o uso de testes automatizados.

E, pelo amor de zahl, robustez eh com ‘z’ e nao tem acento.

Apenas achei que para escrever e manter os testes gasta-se homem-hora e brain power. Acho que vc quer dizer que o processo como um todo é agilizado com a introdução de testes unitários. Devido a sua maior experiência no assunto aceito que vc muito provavelmente está certo. Ainda mais se a linguagem em questão for Ruby.

E debugar e integrar codigo que nao funciona sempre que alguem muda alguma coisa eh “gratis”? Nao entendi a sua logica, aqui.

E pq seria diferente com Java? Voce tem alguma metrica que eu nao conheco?

E como voces preferem implementar testes unitarios, primeiro ou depois do codigo?

Um ou mais testes de aceitacao, preferencialmente em algo executavel/automatizado por user story antes de comecar o desenvolvimento, e depois um teste unitario por…er, unidade.

De preferencia, usando Behaviour Driven Development; senao, vai com TDD mesmo.

Pessoal,

Na empresa onde trabalho, até hoje nao realizamos testes unitários.

E quando já se tem grande quantidade de códigos? Como fazer para adicionar testes?

Deixa o que já tem sem teste e faz apenas para os novos ou faz tudo?

Senhores,

primeiramente eu acredito e utilizo testes unitários, porém, lendo estes artigos, acho que os iniciantes em java poderão cair no erro de programação por testes unitários ou programação para testes unitários.

Essa lógica, me faz lembrar dos irmãos Wright, em que desenvolviam os protótipos e depois, no jargão aqui do sul, soltavam penhasco abaixo e eperavam para ver se voava…

No fundo, essa prática, induz que ao se desenvolver códigos não se precisa de planejamento, de lógica e muito mesnos de experiência. Afinal simplesmentes, se o que você escrever passar nos testes, então seu código será bom…

Eu tive que fazer uma auditoria em um sistema recentemente, em que existia testes unitários para todos os POJOS da aplicação e para uma boa parte das classes de negócio… resumindo: testes mecanicos, sem valor algum, a ponto de encontrar em pojos, coisas do gênero:

public void metodo(String s) { if( s == null ) { throw new UnsupportedOperationException("Not supported yet."); } // ... }

Enquanto que nas classes que deveriam representar estados e implementar uma máquina de estado, sequer validava a transição de um estado para outro…

Outra prática que tenho visto em Curitiba, e a delegação da escrita dos testes para estagiários… com um detalhe importante, os mesmos estão construindo estes testes sem conhecimento das regras de negócios, sem o apoio mínimo de uma documentação… estão apenas escrevendo testes para apresentar ao contratante.

Logo, senhores, testes unitários não deveriam ter o valor que estão querendo dar, fazem parte do ciclo de vida de desenvolvimento de software, especificamente para a fase de testes e deveriam estar sendo menos cobrados na fase de desenvolvimento, ou sequer ser confundidade como parte do desenvolvimento.

A relevância dos testes unitários são proporcionais aos conhecimentos e experiência da equipe de desenvolvimento com relação ao ambiente, aos recursos disponíveis e do grau de definição das regras de negócios.

Em uma equipe experiente, com um escopo bem definido e uma boa documentação, eu rediziria a necessidade dos testes para faixas entre 3 e 5% do projeto, enquanto que no inverso, ou seja, em equipe pouco experiente e com regras de negócios pouco claras, eu recomendaria de 75 a 90% dos artefatos produzidos. (Os % são em relação a cobertura das unidades desenvolvidas)

fw

Discordo completamente; testes unitarios sao parte do ciclo de desenvolvimento sim, e ate agora nao me mostraram um ciclo mais produtivo de desenvolvimento do que o red-green-refactor.

Há um problema muito sério nesta afirmação. Ela parte da premissa que desenvolver sem escrever testes unitários seria de alguma forma mais produtivo do que escrevendo-os (logo a recomedação de evitá-los numa situação em que as pessoas estariam menos propensas a cometer erros).

Essa premissa não faz sentido - e é desse princípio errado que partem a maioria dos argumentos contra testes unitários ao longo do desenvolvimento.

Alguém se habilita? Eu dobro o pagamento

E o que vocês acham das ferramentas que automatizam testes na GUI?
Acho que no fim acaba agregando tanto valor ou mais valor que os testes unitários!

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

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.

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é?

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.

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

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.

Hein?!

bzanchet:

Essa premissa não faz sentido - e é desse princípio errado que partem a maioria dos argumentos contra testes unitários ao longo do desenvolvimento.

Hein?!

:roll: Whats !!!

Os códigos que mais retornam dos testadores aqui na empresa, são dos programadores que NÃO fazem testes unitários.

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.

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:

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

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 ?

Hein?!?!

Alguém entendeu a resposta?

Paulo Silveira:

O que você acha dos testes unitários? Esta prática é adotada na sua empresa? Quais os resultados que você obteve?

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.

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.

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.

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…

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:

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?

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)

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”?

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

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

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.

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.

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.

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.

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…

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

O post todo é sobre TDD em geral.

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.

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:

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

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.

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:

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.

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.

Selenium RC e WebDriver (que vai virar Selenium 2), fazem um trabalho bem decente na hora de testar interfaces Web, e sao super faceis de usar.

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.

2. Para ter testes como documentação de requisitos funcionais você precisa trabalhar com testes funcionais, não unitários, automatizados. No meu projeto anterior tinhamos uma DSL em Ruby que guiava o Seleniume ia mais ou menos assim:

describe "A standard text search"do

  before :all do
   ingest_test_data
  end


 it "should display only results from a given state"do
  on SearchPage do
   search_for "automobile"
   filter_by :state => 'New South Wales'
  end

  on ResultsPage do
   entries.size.should eql(3)
   entries.each{|entry| entry.should be_an_ad_from('Victoria')}

   header.text.should eql("Results found for 'automobile' in 'New South Wales'")
   header.searchbox.contents.should eql("automobile ")
   header.filters.should be_filtering_by('New South Wales')
 end
end

Mas atualmente eu estou referindo o StoryRunner:

Scenario "file is already in registro's format" do
        Given "A file in Registro's format" 
        And "A parser for log files in DSL"
        When "Parser parses file"
        And "The resulting DSL lines are interpreted"
        Then "A timeline should be created with all entries in the file"
end

Serio que ha diferenca? So se for o numero de paginas.

O que vc acha que é TDD então além de testes unitários guiando o desenvolvimento?

O que vc descreveu é sim teste unitario, da unidade facade.

O seu cliente entende alguma coisa nessa sua documentacao de requisitos? Ou é por isso que vc acha word uma alternativa viavel?

De uma olhada no FIT, acho que ele pode [editado] ajudar nessas situacoes.

O que eu acho que o mais importante sobre testes unitários é a possibilidade de fazer o teste de regressão de forma limpa e automática. Existe alguma coisa mais brochante que você entregar alguma correção/nova funcionalidade do sistema e surgir um problema novo ou já supostamente corrigido no passado? Isso gera um desgaste enorme.

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.

E acredito também que os teste unitários para linguagens dinâmicas são imprescindíveis, pois você pode acabar com o seu sistema com apenas um erro de digitação de uma forma assustadoramente fácil.

Vejam bem, não que testes unitários sejam dispensáveis em linguagems compiladas, mas neste caso eu pego muitos erros de digitação em tempo de compilação, mas não todos

Na industria de qualquer coisa testes automáticos e garantia de qualidade são assuntos velhos velhos velhos.

Nos meados dos anos noventa eu trabalhava em uma empresa que fabricava máquinas para testar produtos fabricados por mais diversas industrias.
Pensando hoje, o que eles faziam era uma forma de teste unitário e teste funcional.
Teste unitário quando a máquina testava os componentes do sistema e teste funcional quando a máquina testava o produto como um todo.

Eu seja, estamos atrasados pra K C T :shock:

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 ?

microfilo:

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…

Pode pegar QUALQUER cliente, de qualquer ramo, de qualquer projeto… pergunte para ele: Você quer ver um requisito implementado ou um requisito documentado? O que vc acha que ele vai responder?

Me parece que vocês entenderam mal o que o Dieval falou.

Eu li e reli o que ele escreveu e sou obrigado a concordar com quase tudo.
E muito do que ele falou não cai em contradição com o que vocês falaram.

Se testes unitários servem como documentação e são importantes no ciclo de desenvolvimento, então eles devem ser tratados como artefatos importantes. Ele criticava justamente a postura de várias empresas de jogar os testes para os estagiários, acabarem com uma pilha de testes que não testam nada e não documentam nada. Pior do que isso, a empresa ainda usa esse teste praticamente inútil como “critério de qualidade”, na boa e velha filosofia de “passou no teste está ok”.

Nesse caso, escrever testes desse jeito não só é inútil como também uma perda de tempo. Se o trabalho desses estagiários estivesse sendo gasto em uma atividade mais útil (como até mesmo preparar café), a empresa já lucraria mais.

Um ciclo de desenvolvimento sério deve tratar o teste unitário de maneira séria. Deve se preocupar se ele realmente reflete os requisitos de negócios (quando esses requisitos podem ser testados de maneira unitária). Deve garantir que o desenvolvedor entre em contato com o teste e corrija o código (ou muitas vezes o teste). O time também deve ter a preocupação de, em caso de um erro descoberto, corrigir o teste antes do código.

E em parte eu também concordo com o fato de que numa equipe experiente a validade do teste unitário cai um pouco. A equipe experiente refatora bem, modula bem, costuma a testar asserções, exceções e preocupa-se com diversas situações de erro naturalmente. Entretanto, a equipe experiente valoriza o teste unitário e sabe seu valor antes uma refatoração.

Em resumo, não adianta fazer teste para inglês ver. Mas também não adianta cair no conto da carochinha dos vendedores de JUnit e começar a achar que o teste unitário é a solução dos problemas, que ele vai mudar a forma dos seus programadores pensarem e que basta te-los para se ter qualidade. Eles são bons? Sem dúvida? Importantes? Muito. Mas são só mais uma das partes do ciclo de desenvolvimento, que tem várias.

O que eu discordo do Dieval é que acho que numa equipe experiente a importância do teste unitário cai um pouco, mas não muito. Seria o suficiente para arriscar um módulo do sistema sem eles em caso de pressa, e faze-los depois, só depois da release sair. Eu não reduziria ele a percentuais tão baixos. Agora, não dá para só bater em cima dessa tecla, sem levar em conta todo o resto que ele falou, que achei extremamente válido.

Em TDD, para implementar um caso de uso você roda os testes umas 200 vezes. Você roda os testes umas 20 vezes por hora. É importante que os testes rodem rapidamente. O Feedback tem que ser rápido.

microfilo:

peczenyj:

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.

Uma coisa é vc verificar se uma tela trata uma determinada exception. Outra é se as classes/métodos/funções tratam as exceptions de forma correta.

Não que o teste de GUI seja menos importante, ele é importante, mas vc precisa ter uma GUI para executa-lo, certo? Imagine que vc tem um bug de GUI que impossibilite que vc acesse 30% dos casos de teste – vc vai gerar um novo deploy e reiniciar o ciclo de testes depois de corrigido esse BUG? Quantos Bugs esse caso não ocultou?

microfilo:

peczenyj:

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.

Amigável significa trabalhar com record-playback com algum tipo de parametrização e/ou controle de transações? Pode ser muito bom para testes de regressão de código mas estamos falando de unidade. Dizer que uma ferramenta dessas é mais facil ou melhor que o JUnit é contra-produtivo pois o ideal é que ambas trabalhem juntas com objetivos diferentes.

Plugue uma ferramenta de cobertura de código como o EMMA e veja a porcentagem para ambos os casos. É absurdamente mais facil incrementar a cobertura com testes unitários (quando a arquitetura permite: quando não permite vc pode alterar a arquitetura), mas com testes de GUI vc vai chegar a um limite que, para ultrapassar, vai ter q adotar algum método invasivo (como injetar código de teste).

Felizmente o uso dessas duas abordagem pode maximizar a qualidade do software gerado. Entretanto qualidade é um termo subjetivo que normalmente reflete a opinião do cliente. De nada adianta uma montanha de testes se o software não faz o que o cliente quer.

xandroalmeida:

O que eu acho que o mais importante sobre testes unitários é a possibilidade de fazer o teste de regressão de forma limpa e automática. Existe alguma coisa mais brochante que você entregar alguma correção/nova funcionalidade do sistema e surgir um problema novo ou já supostamente corrigido no passado? Isso gera um desgaste enorme.

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.

…

Na industria de qualquer coisa testes automáticos e garantia de qualidade são assuntos velhos velhos velhos.

Nos meados dos anos noventa eu trabalhava em uma empresa que fabricava máquinas para testar produtos fabricados por mais diversas industrias.
Pensando hoje, o que eles faziam era uma forma de teste unitário e teste funcional.
Teste unitário quando a máquina testava os componentes do sistema e teste funcional quando a máquina testava o produto como um todo.

Eu seja, estamos atrasados pra K C T :shock:

Xandro, MUITO bem escrito e posicionado. Parabens. Realmente nada pior do que mais bugs na correcao de bugs existentes…

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.

Documentos Words podem ser utilizados para ser entendível pelos usuários, mas na maioria das vezes, é melhor deixar os testes executáveis. Como falei, o cliente geralmente não entende QUALQUER documentação textual detalhada de requisitos. Isso é um trabalho seu, e não dele.

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.

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?

ViniGodoy:

E em parte eu também concordo com o fato de que numa equipe experiente a validade do teste unitário cai um pouco. A equipe experiente refatora bem, modula bem, costuma a testar asserções, exceções e preocupa-se com diversas situações de erro naturalmente. Entretanto, a equipe experiente valoriza o teste unitário e sabe seu valor antes uma refatoração.

Em resumo, não adianta fazer teste para inglês ver. Mas também não adianta cair no conto da carochinha dos vendedores de JUnit e começar a achar que o teste unitário é a solução dos problemas, que ele vai mudar a forma dos seus programadores pensarem e que basta te-los para se ter qualidade. Eles são bons? Sem dúvida? Importantes? Muito? Mas são só mais uma das partes do ciclo de desenvolvimento, que tem várias.

O que eu discordo do Dieval é que acho que numa equipe experiente a importância do teste unitário cai um pouco, mas não muito. Seria o suficiente para arriscar um módulo do sistema sem eles em caso de pressa, e faze-los depois, só depois da release sair. Eu não reduziria ele a percentuais tão baixos. Agora, não dá para só bater em cima dessa tecla, sem levar em conta todo o resto que ele falou, que achei extremamente válido.

Alguns problemas de uma suite de testes com cobertura limitada:

Quem definiria o criterio para escrever ou nao um determinado teste?

Qual a vantagem de se ter uma suite incompleta, e portanto, que nao serve como testes de regressao (como bem lembrou o Xandro)?

editado: após reler o texto do ViniGodoy :oops:

Você realmente leu o que eu escrevi?

Como você modela dados nas aplicações que você faz? Os dados também não são requisitos? Se o cliente diz “o pedido de venda tem que ter um campo de observação” isso é um comportamento ou é um requisito que faz parte da visão estática do sistema? (leia meu artigo na MundoJava que será publicada neste mês sobre Domain-Driven Design)

Difícil… está no código e nunca é deixado pra trás. Se o requisito muda a primeira coisa que alteramos é a classe de teste. Entra no ciclo TDD. O código tem tendência a mostrar problemas mais facilmente. Documentos fora do código tendem mais a serem esquecidos.

Sim… e alguma vez você viu isso funcionando? Já tentou avaliar o custo benefício dessa abordagem? Já conseguiu fazer isso sem gastar centenas de milhares de dólares em ferramentas caras?

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.

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 ?

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.

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.

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 ?

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.

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

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

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

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

cmoscoso:

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.

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.

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

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.

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.

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.

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.

De acordo. No meu projeto solo por exemplo nao uso integracao continua e Collective Code Ownership.

Bem, fugindo um tanto do assunto, mas ainda falando nele:

E se os testes tivessem comentários, e destes comentários fosse gerada uma documentação?
Tipo:

@Documentacao("RF1.2 - blablablabablablabablababla")   
public void metodoTestaDocumentaEFazCafe(){
 //xxx
}

Aliás, existe alguma ferramenta que faça isso?

Qual seria a vantagem, Rafael? O benefício de testes é que a descrição dos requisitos não pode estar desatualizada ou o build não passa.

Se você apenas mudar a documentação textual de lugar só vai usar o Eclipse ao invés do OpenOffice.

Seria um tanto mais prático para lugares que exigem ter um maldito .doc/.pdf/.html com os requisitos em papéis.

Tava só divagando aqui mesmo.

Creio que não entendi aqui.
O que você se refere com ‘descrição do requisito’? Um documento?

Rafael Nunes:

Creio que não entendi aqui.
O que você se refere com ‘descrição do requisito’? Um documento?

pcalcado:

[…]Mas atualmente eu estou referindo o StoryRunner:

Scenario "file is already in registro's format" do Given "A file in Registro's format" And "A parser for log files in DSL" When "Parser parses file" And "The resulting DSL lines are interpreted" Then "A timeline should be created with all entries in the file" end

Essa é a típica pergunta que um cliente frustrado com fábrica de software faz. Depois da segunda iteração, se você conseguir ficar parceiro dele essas perguntinhas provocativas tendem a desaparecer.

Lembra que falei aqui a minha frustração com ambiente EJB3 com relação a TDD? Dá para rodar no Microcontainer, mas é lento. Cada rodada de teste demora de 10-20 segundos. Ninguém para muito pra pensar nisso, mas é simplesmente ridículo que o EntityManager demore 10 segundos para subir com um mapeamento de umas 100 entidades.

Colocaria isso num requisito? Como assim? Num texto? Num dicionário de dados? :shock: XP, DDD, MDA, DSLs, no fundo, tudo isso tenta fazer com que tenhamos menos “layers” nos nossos artefatos, aproximando o software do negócio. Se a tecnologia permite hoje que a visão lógica e a visão fisica seja a mesma, porque não juntar a necessidade à solução? Você não sonha um dia ter uma ubiquitous language implementada numa DSL ou PIM que resolva o negócio de maneira executável?

Acho que o CV já respondeu isso da melhor maneira possível… dá margem a criar o VDD (Vodka-Driven Development). TDD não resolve tudo. XP não resolve tudo. Nem mesmo a computação resolve tudo. Não procure a bala de prata.

microfilo:

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.

Cara, na boa, deve ser meio caro desenvolver software na tua visão… como falei, matriz de rastreabilidade de requisitos CMMI-like não é problema para equipes ágeis, então, não precisamos dessas ferramentas.

Isso acontece em equipes que não tem compromisso com o software que estão produzindo. O infeliz que subiu código sem passar pela suíte de testes e os demais membros da equipe que não cobraram dele o fato. Contra cultura ruim e burrice não tem muito para ser feito, nem o JCDD tem alguma chance. Ou a equipe tem compromisso e atitude no sentido de produzir resultado de boa qualidade ou automação de testes só vai ser mais um passo inútil no processo.

Pela minha experiência, a equipe é encorajada a chamar a atenção daqueles que quebrarem o build. Isso é saudável e normalmente acaba aumentando o comprometimento do time. Por isso que posse coletiva de código é fundamental, pois o outro não fez besteira no código dele, mas cagou o seu.

microfilo:

cv:

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.

Certo, eu tenho a visão dos requisitos daquela unidade sendo testada, e da visão do todo? Dos requisitos como um todo?

pcalcado:

[…]Mas atualmente eu estou referindo o StoryRunner:

Scenario "file is already in registro's format" do Given "A file in Registro's format" And "A parser for log files in DSL" When "Parser parses file" And "The resulting DSL lines are interpreted" Then "A timeline should be created with all entries in the file" end

Não são perguntas provocativas, o cara quer isso e pronto! Assim que ele trabalha, assim que todos os outros fornecedores dele trabalham!
Acho que a questão é: se o cara te contratou, você tem que trabalhar nos termos dele, fazendo o máximo para entregar o software com qualidade. Não é por que o cara te obriga a usar Use Case e use case tem a tendência de ficar desatualizado que eu vou deixar ser descuidado e efetivamente deixar o use case ficar desatualizado! Não da para querer mudar a cultura do cliente. O cara quer ser atendido de uma determinada maneira, se der para mostrar para ele como funciona o agile e ele gostar, ok, ótimo, se ele quiser usar waterfall da vida, eu prefiro atender ele nos termos dele.

Não rola só rodar os testes unitários “leves” em quanto desenvolve e deixar os testes mais pesados para rodarem uma vez por madrugada?

Dependendo do caso, colocaria num texto da documentação do requisito - não ficaria detalhando informações sobre a minha estrutura de tabelas num documento de requisitos.

Eu acho que uma equipe deisleixada o suficiente para deixar a documentação de requisitos desatualizada também poderia deixar os testes desatualizados. O problema não é ser um documento word em si, o problema é o desleixo mesmo. É lógico que der 300 mil tipos de documentação não ajuda.

rodrigoy:

Cara, na boa, deve ser meio caro desenvolver software na tua visão… como falei, matriz de rastreabilidade de requisitos CMMI-like não é problema para equipes ágeis, então, não precisamos dessas ferramentas.

Acho que eu já me expressei no post acima: se a equipe é desleixada o suficiente para deixar um .doc desatualizado, é possível que ela deixe um teste desatualizado também

Gerencia de configuração não ajuda aqui. Quando eu me referi a código de produção, eu quis dizer o código normal, excluindo os testes.

Isso não resolve o problema

cv:

Nao? :mrgreen:

louds:

Isso acontece em equipes que não tem compromisso com o software que estão produzindo. O infeliz que subiu código sem passar pela suíte de testes e os demais membros da equipe que não cobraram dele o fato. Contra cultura ruim e burrice não tem muito para ser feito, nem o JCDD tem alguma chance. Ou a equipe tem compromisso e atitude no sentido de produzir resultado de boa qualidade ou automação de testes só vai ser mais um passo inútil no processo.

louds:

Pela minha experiência, a equipe é encorajada a chamar a atenção daqueles que quebrarem o build. Isso é saudável e normalmente acaba aumentando o comprometimento do time. Por isso que posse coletiva de código é fundamental, pois o outro não fez besteira no código dele, mas cagou o seu.

Seria um tanto mais prático para lugares que exigem ter um maldito .doc/.pdf/.html com os requisitos em papéis.

Tava só divagando aqui mesmo.
No caso de projetos Java que já possuem uma suite de testes boa, se existisse alguma coisa que pudesse ler as classes da sua suite e através dos métodos gerasse um HTML com a spec seria interessante para apresentar para quem não vai ler o código mas precisa de outros tipos de documentos.

Ex:

class EstoriaXXX {
   public void testDeveFazerAbcERetornarXYZ() {
       //Teste
   }
   public void testDeveRetornarXpto() {
       //Teste
   }
}

Esse código poderia ser lido e gerado um HTML ou qualquer outro tipo de arquivo usando o nome da classe como User [Story|Use Case|Coloca seu nome favorito aqui] e cada método as funcionalidades desta. Poderia ser usado Camel Case como convenção para separar acrescentar os espaços ou um underline, ou qualquer outra coisa. O interessante é que para projetos com suites de teste já prontas adiantaria muito.

Ficaria assim a documentação:

• Estoria XXX
      - Deve fazer abc e retornar XYZ
      - Deve retornar xpto

Podendo usar templates, css e toda parnafenalha que desejar.

Hoje em dia é melhor procurar outras alternativas como RSpec. Mas de qualquer forma o JUnit ainda serve bastante sem sombra de dúvidas.

O fato é que eu estou pra conhecer um bom programador que goste de documentar alguma coisa. No caso dos testes como especificação, ao perceber que aquilo de fato “executa” e te ajuda a guiar o Design da sua aplicação, facilitando o seu trabalho, o programador tende a encarar a coisa de forma completamente diferente do que um documento do word.

Testes unitários defasados retornam erro num click de botão, ou a cada commit no CVS/Subversion.

Documentação defasada retorna confusão quando alguem resolve ler a sério.

microfilo:

rodrigoy:

Essa é a típica pergunta que um cliente frustrado com fábrica de software faz. Depois da segunda iteração, se você conseguir ficar parceiro dele essas perguntinhas provocativas tendem a desaparecer.

Não são perguntas provocativas, o cara quer isso e pronto! Assim que ele trabalha, assim que todos os outros fornecedores dele trabalham!
Acho que a questão é: se o cara te contratou, você tem que trabalhar nos termos dele, fazendo o máximo para entregar o software com qualidade. Não é por que o cara te obriga a usar Use Case e use case tem a tendência de ficar desatualizado que eu vou deixar ser descuidado e efetivamente deixar o use case ficar desatualizado! Não da para querer mudar a cultura do cliente. O cara quer ser atendido de uma determinada maneira, se der para mostrar para ele como funciona o agile e ele gostar, ok, ótimo, se ele quiser usar waterfall da vida, eu prefiro atender ele nos termos dele.

Se você engole qualquer coisa só pra fechar contrato ou acredita que seu cliente sabe mais de desenvolvimento do que você, só posso desejar boa sorte na hora de entregar o seu produto final.

Apropósito, essa é a sua posição ou da empresa onde você trabalha?

O bom fornecedor entrega aquilo que o cliente precisa não o que ele pede. Pode ter um gap muito grande entre esses dois. Não à força, mas pode ter certeza que quando uma montadora, um hospital, uma indústria chega pra você e pede “quero casos de uso, quero UML, quero Java, quero BPM, quero CMMI-like” eles não têm a mínima noção do que são essas coisas. É um mito que se criou no mercado. O que eles querem é uma solução para problemas de negócio. A incapacidade de certos fornecedores de separar aquilo que é problema deles dos problemas do cliente fez essa confusão toda acontecer, inclusive a aberração do Waterfall. Eu particularmente prefiro nem entrar no projeto se vejo que o cliente é burro e depois vai querer me usar como bode expiatório.

Não… não rola… Discutimos isso na thread que já postei aqui.

Tá bom, mas saiba que você não precisa dessa ambiguidade. Um diagrama de classes pode ser um documento de requisitos, um MER pode ser requisitos, uma anotação pode ser um requisito. Se o requisito é executável eu não preciso de matriz nenhuma.

http://www.agilemodeling.com/essays/agileRequirementsBestPractices.htm#ExecutableRequirements

Sim… já comentei sobre isso! Cara, é mais difícil jogar a poeira pra baixo do tapete com EMMA, TDD. Documento Word aceita qualquer porcaria que você escreva!

microfilo:

Eu não disse nada sobre matriz de rastreabilidade de requisitos CMMI-like. Disse sobre rastreabilidade entre “artefatos”.

Se isso não é CMMI-like, o que é?

Se o cliente pagar por isso, não vejo problema em documentação não executável.

Suite de testes é bom senso da empresa desenvolvedora, implica na qualidade de seu produto e melhor entendimento dos códigos pelos desenvolvedores.

Temos no manifesto ágil a prioridade de sofware em funcionamento que documentação abrangente, porém temos também priorizar colaboração com o cliente do que negociação de contratos. Se o cliente pede e faz questão de documentação .pdf, e paga por isso, pq não colaborar com ele?

Olá s4nchez,

como assim engolir? Na realidade não vejo muita opção. Pelo menos tenho visto mais clientes que acham que sabem mais que o a equipe de desenvolvimento do que desenvolvedores agilistas. O único lugar que vejo desenvolvedor agilista é em fórum de discussão, reuniões e eventos. Fora isso, conto nos dedos da mão direita os programadores que conheci pessoalmente que ao menos usassem TDD.

Enfim, qual é a dica para se dar ao luxo de não engolir as situações citadas pelo Rubem? :mrgreen:

Com integracao continua e medicao de cobertura de testes nao da pra “deixar um teste desatualizado”. Cabe a equipe se policiar, mas aparentemente as equipes onde vc trabalha preferem ser tratadas como criancas, entao talvez a gerencia do projeto tenha que acordar pra vida, tambem.

Exatamente. Leia mais sobre gerencia de configuracao de software

Não é questão de engolir qualquer coisa… Bom, os clientes muitas vezes são empresas de TI ou que possuem ambientes de desenvolvimentos grandes, maduros e estáveis - muitas vezes ambientes de desenvolvimento que funcionam razoavelmente bem usando waterfall-like. Então eles acreditam ter um grande know-how em desenvolvimento de software - quem somos nós para falar que eles não têm?
Se ele falou que quer a coisa assim ou assado e você acha que não é a melhor maneira, não acho que seria correto simplesmente rejeitar o projeto - as vezes com o tempo você consegue até mostrar as vantagens de outras abordagens - soa até arrogância, eu acho…
Basicamente isso, se o cara tem um forma de trabalhar, não quer mudar no primeiro momento, entao sigamos o processo do cara. Se ele quiser que a gente melhore o processo do cara, a gente melhora :).

Até existem clientes que aí oque eles realmente querem que você faça, não improta como, ele define o que e você define como. Aí é bem interessante, já surgiu algumas execuções utilizando agile quando isso acontece - as vezes o cliente contrata para ajudar a defin ir o seu processo interno, aí são outros quinhentos.

Independente se o cara sabe a melhor forma de trabalhar ou não, respeito é bom e eu (e ele) gostamos.

Felizmente, os projetos onde eu tenho trabalhado atualmente não são problematicos como os ambientes que eu descrevi

Eu já li bastante sobre isso, mas não ainda não saquei o seu ponto.

Então isso necessariamente é algo ruim?

Se eles usam waterfall-like, qualquer pessoa que sabe desenvolver software de verdade e já experimentou os benefícios do desenvolvimento iterativo se torna mestre para falar que eles não sabem desenvolver software. O fato do ambiente ser grande, maduro e estável não necessáriamente diz que é EFICIENTE (e geralmente não é).

Mas OK, eu tenho uma postura radical com relação a isso, e tenho pouca paciência com gestores burros que se acham os gostosões, desculpem qualquer exagero. Pode não ser muito bom para meu bolso, mas já dropei projetos por conta disso. Não é uma decisão emocional, é só um risco que não dava para aceitar (qualquer jogador de Poker ou home-broker sabe do que estou falando).

microfilo:

rodrigoy:

Se isso não é CMMI-like, o que é?

Então isso necessariamente é algo ruim?

É bonito na teoria, mas na prática é um inferno. Especificações executáveis são a únicas que é viável verificar contra o software. O problema de ter toneladas de documentação é quando um requisito escapa de ser realizado na documentação (nenhuma equipe é perfeita). Com testes automatizados e um mínimo qualidade no processo esse tipo de coisa não resiste a primeira execução integrada do build. No caso de documentação no word nada garante isso.

Achar que softwares de rastreabilidade resolvem isso é sales pitch ou ingenuidade pois elas exigem toneladas de trabalho manual para serem usadas e no final até as equipes mais disciplinadas acabam fazendo vista grossa para grande parte do que acontece.

microfilo:

CMMi 1.2:

SP 1.4 Maintain Bidirectional Traceability of Requirements

Maintain bidirectional traceability among the requirements and work products.

The intent of this specific practice is to maintain the bidirectional traceability of requirements for each level of product decomposition. (See the definition of ?bidirectional traceability? in the glossary.) When the requirements are managed well, traceability can be established from the source requirement to its lower level requirements and from the lower level requirements back to their source. Such bidirectional traceability helps determine that all source requirements have been completely addressed and that all lower level requirements can be traced to a valid source.

Então isso necessariamente é algo ruim?

Ruim? Se você ver, as idéias do CMMi não são todas ruins, a maneira como o mercado interpreta é que é um cancer. De qualquer forma:

1. A preocupação por uma matriz de rastreabilidade “cheira (ou fede) waterfall”: Dá a entender que o requisito levará meses para ser implementado. A preocupação com “será que atendemos o requisito?” demonstra também que o usuário demorará meses para ver a aplicação.

2. Essa visão é antiquada: Como falei, temos várias alternativas de demonstrar os requisitos de modo executável. Assim, o “source requirement” é o mesmo que o “lower level requirements”. Pode ter certeza que uma consultoria CMMi não vai aceitar um @Valid do hibernate validator como “source” de requisitos. Vc compreende? Se você usar os benefícios da tecnologia você não precisa de rastreabilidade bidirecional. E se você não tem essa rastreabilidade, segundo o SEI, seu processo não é maduro! Não soa estranho?

3. Matriz de rastreabilidade “cheira escopo-fechado”: É uma presunção forte que os “source requirements” são verdade lavrada em cartório. Requisitos são incertos até o sorriso do usuário aparecer. Esse “completely addressed” dá a entender que os requisitos não vão mudar.

4. Teoria da Conspiração: Passei por 2 implantações de CMMi e meu sentimento foi que era meio impossível um mortal manter uma matriz de rastreabilidade na mão. Talvez uma matriz de Sudoku 100X100 seja mais fácil. No fim, vinha aqueles vendedores de fabulosas ferramentas que “faziam isso sozinho pra você” por alguns milhares de dólares. Será que é por isso que eles pedem essa matriz?

[editado só correções ortográficas confusas]

Olá s4nchez,

como assim engolir? Na realidade não vejo muita opção. Pelo menos tenho visto mais clientes que acham que sabem mais que o a equipe de desenvolvimento do que desenvolvedores agilistas. O único lugar que vejo desenvolvedor agilista é em fórum de discussão, reuniões e eventos. Fora isso, conto nos dedos da mão direita os programadores que conheci pessoalmente que ao menos usassem TDD.

Enfim, qual é a dica para se dar ao luxo de não engolir as situações citadas pelo Rubem? :mrgreen:

A questão é que muitas vezes os dois lados que fecham um contrato de software não sabem tanto assim sobre software, justamente porque estão mais preocupados com decisões comerciais. Neste caso cabe ao responsável interno tentar fazer valer as opiniões de quem é responsável pelo desenvolvimento em si. Pra isso é que serve ter poucos desenvolvedores ótimos do que uma cacetada de desenvolvedores medíocres, como normalmente acontece. Se a cultura de desenvolvimento da empresa não for ditada por desenvolvedores, vai ser ditada por quem?

Lógico que dá para flexibilizar algumas coisas, mas esta história de “fazemos qualquer negócio” é que mata muitas software houses hoje em dia: a cultura de desenvolvimento é ditada pelos clientes, e cada novo cliente é uma nova dor de cabeça. De que adianta fechar centenas de contratos se vai acabar como as empresas de três letrinhas?

Qual o problema de dizer que o cliente esta errado?
Mesmo que tu esteja como outsourcing dentro do cliente, dar sugestões nunca tirou os dedos de ninguem. Agora se esta como consultoria, ver um fato errado e se omitir é pedir pra mais cedo ou mais tarde ser xingado pelo cliente. Já vi isso com os proprios olhos…uma consultoria X que sabia que tava errada mas não quiz falar pro cliente, o cliente contratou a consultoria Y que avisou ele do problema…advinha o que aconteceu com a consultoria X?

Um sonoro SIM. Estamos até levando para nossos clientes muitas das práticas.

cv:

Otimos. O design das aplicacoes eh assustadoramente melhor, e todo tipo de metrica que a gente ja passou nos projetos eh melhor de maneiras significativas (e a TW lancou um whitepaper sobre essas metricas que eu nao estou conseguindo achar agora por estar razoavelmente bebado/cansado/sem saco).

Concordo 100%.

Cv ja curou a ressaca pra passar o paper?

]['s

Pessoal,

Então recapitulando, pode se dizer que o programador que não faz testes unitários não é profissional?

Já perseveram quanto tempo vc deixou de usar em diagnostico de falhas e debugging desde que começou a usar TDD?

Abraços,
Juan.

Juan,

Essa afirmação é bem forte. Eu li isso uma vez no blog do Phillip. Eu, apesar de ser totalmente adepto não usaria uma frase como esta, pois a maioria dos que estão aqui no forum defendendo o uso de testes (inclusive eu), já programou por muito tempo sem o uso destes, e nem por isso não eramos profissionais. O ponto importante, que é o que eu acho que ele quiz dizer é que a abordagem de testes automatizados tem sido martelada faz tempo e o pessoal nem se interessa pelo assunto. Ao menos se as pessoas tentassem ver como que funciona, os ganhos, etc. Essas pessoas preferem simplesmente ignorar as coisas e usar argumentos totalmente evasivos contra a prática de testes automatizados.

Espero que essa mentalidade mude.

Essa discussão é realmente inútil, como muitos testes unitários por aí que não testam nada e são feitos por estagiários de saco cheio como o Leonardo falou!

Cara, primeiro defina PROFISSIONAL. O que é um PROFISSIONAL? Escolha abaixo:

1. É um cara que tem um emprego e ganha para programar?

2. É um cara que ganha bastante para programar, acima da média do mercado?

3. É um cara foda (ou que se acha foda) como algumas figurinhas marcadas desse forum?

4. É um cara que tem um cargo sênior de programação?

5. É um cara que tem uma carreira longa e comprovadamente de sucesso?

Falar que um programador que entrega uma linha de código sem testes UNITÁRIOS é irresponsável, é o mesmo que falar que o cara que faz um programa no notepad é irresponsável.

Agora se algumas pessoas acham que TDD, JUnit e essas coisas agilizam a implementação de um projeto então sejam felizes! So be it! Mas isso não tem nada haver com qualidade…

Só para lembrar o pessoal: existem outras formas de testar além do teste unitário, ok? Pensem nisso só um pouquinho…

Duvido muito, especialmente porque testes unitários não garatem que o sistema funciona, apenas as unidades. Existem muitos casos aonde testes unitários não valem o esforço (como em sistemas embarcados ou próximos demais ao hardware), aonde estes funtionais e de integração são muito mais eficientes e baratos.

Testes unitários tem uma importância ímpar na hora de ajudar você a definir o design dos seus objetos, mas eles não são a única solução pra testar nem garantir a qualidade de um software.

Sem falar que essa obcessão por testes unitários está levando a Herança para a fogueira da inquisição.

Herança tem sim o seu uso, é importante pra baralho e não é porque no passado você fez um extends Properties (eu também já fiz) é que você vai correr de herança como o diabo corre da cruz.

Um sistema grande e de alto nível sem herança é totalmente inviável. Se você não acredita é porque você nunca fez um sistema/framework realmente sério.

E viva o mengão!

Poderia citar alguns exemplos mais confiáveis que se encaixam em todas as fases de desenvolvimento ?

Obrigado!

Não estamos falando exclusivamente de testes unitários, ninguém defende isso. Mas um programador que não usa de testes automatizados é um irresponsável fanfarrão. É impossível construir um sistema extremamente complexo no prazo e com qualidade sem usar testes automatizados - desafio qualquer um a me mostrar um caso que prove o contrário disso. Não estou falando de sistemas grandes, mas sim de sistemas complexos.

Um micreiro que diz ser possível construir tal sistema sem automação de testes não merece ser chamado de desenvolvedor, muito menos profissional.

Não consigo entender por que raios precisa de mais argumentos que a porcaria da realidade para mostrar que testes automatizados são extremamente saudáveis a qualquer projeto. Ou você automatiza, ou você corre atrás do próprio rabo o tempo todo.

Bom, se é para dar opiniões, a minha é totalmente o contrário. Hoje em dia só uso herança quando sou obrigado (a ferramenta que eu estou usando me obriga).

Mas isso é outra discussão…

Eu acho o JForum bastante complexo e até onde eu sei ele nunca teve testes automatizados. Agora na versão 3.0 que parece que ele terá testes automatizados…

Ach que eu já descobri o que é um programador PROFISSIONAL: resposta 3)

!!! Get Real !!!

Olá

Programador profissional é aquele que faz programa para viver. Os que fazem programas ou frameworks para aprender ou para ter seu próprio modo de fazer as coisas, são diletantes.

[]s
Luca

A vida seria muito chata se isso fosse verdade. E o pior é que muitas vezes o pessoal do segundo grupo acaba ganhando mais e conseguindo mais sucesso e realização do que o pessoal do primeiro grupo. Mas não são profissionais, porque um programador profissional é …

Pois é testes unitarios sem fazer TDD, e feitos por estagiarios de saco cheio, pareceria ser unicamente um desperdiço, não são esses testes unitarios que eu pelo menos me refiro.

Agora testes unitarios no contexto do TDD fazem toda a diferença. Eu por exemplo trabalhei em projetos de software embarcados, repetidoras microondas, centrais telefônicas para suporte de serviços de chamadas massivas com cargas ultra altas, e um monte de produtos que se você não tivesse feito TDD o prejuiço seria gigantesco.

Tem que entender que Teste Unitario como estamos falando aqui de TDD na verdade nada tem a ver com testes e sim com design, nos ajudam a formalizar qual é o objetivo, eles te ajudam a pensar no teu design e te ajudam a que você possa evoluir teu design fazendo refactoring sem medo de quebrar alguma coisa, e sair da ideia de equipe que esta ganhando não se mexe, e passar para em todo momento eu mexo no codigo porque posso melhorar ele continuamente porque tenho uma rede de segurança para me indicar o que quebrei.

Nenhuma das opções acima, talvez profissional seja alguem que tem vergonha de ver quanto seus bugs atrapalham a vida de muita gente, alguem que tem orgulho daquilo que produz, alguem que esta a procura constante de excelência.

Digamos que um cirurgião que não tem um processo para contar a quantidade de gases que são usadas no paciente para quando fechar ele eles possam ter um “assert” dando a conta original, não é um teste que agrega valor depois de fechado, agrega valor durante o “procedimento”, assim como testes unitários nos permitem sair da implementação de uma feature com certeza de que estamos fazendo aquilo que imaginamos que faríamos no inicio.

O cirurgião que corre esse risco sabendo que o ideal é contar as gases, ele é mais profissional ou menos profissional daquele que toma o cuidado de conta-las?

Abraços,
Juan

nadele:

Luca:

Programador profissional é aquele que faz programa para viver. Os que fazem programas ou frameworks para aprender ou para ter seu próprio modo de fazer as coisas, são diletantes.

A vida seria muito chata se isso fosse verdade. E o pior é que muitas vezes o pessoal do segundo grupo acaba ganhando muito mais e conseguindo muito mais sucesso do que o pessoal do primeiro grupo. Mas não são profissionais, porque um programador profissional é … (vide resposta 3)

Diletante: O que se ocupa de qualquer assunto por gosto, e não por obrigação.
Profissional: Pessoa que faz uma coisa por profissão.
Inveja: Sentimento de cobiça à vista da felicidade, da superioridade de outrem

Olá

aleck:

Diletante: O que se ocupa de qualquer assunto por gosto, e não por obrigação.
Profissional: Pessoa que faz uma coisa por profissão.
Inveja: Sentimento de cobiça à vista da felicidade, da superioridade de outrem

Repare que na minha resposta eu NÃO exclui o profissional que trabalha por prazer que foi sempre o que eu tentei fazer desde que me formei engenheiro em 1970.

E não entendi porque incluiu inveja na sua mensagem. Você acha que alguém faz frameworks por inveja? Ou que eu tenho inveja de quem faz? Explique-se.

[]s
Luca

Como um ‘profissional’ fica confidente para refatorar um sistema sem testes unitários (e demais) automatizados?

Em uma realidade alternativa eu sou um excelente programador ABAP e meus códigos resolvem 100% dos problemas dos clientes.

Os testes nunca encontram bugs, mas eu não faço testes unitários. Meus codigos fontes utilizam uma lógica que para mim é trivial, utilizo recursos arcanos e otimizações de forma totalmente obfuscada.

Por mais que a minha empresa me considerasse O cara, e eu era super profissional em todos os momentos, não deixei entidades do tipo “testes unitarios”, documentação ou mesmo comentários de código uteis. O sistema funcionava mesmo assim.

Um dia eu resolvi sair do meu emprego e programar os bits de um satélite que vai investigar um planeta distante… e a empresa pediu para um grupo de 6 desenvolvedores que fizesse uma pequena alteração no sistema… o resultado dessa história é: não deixei nada que ajudasse uma outra equipe e MESMO que o meu código tivesse comentarios totalmente esclarecedores, como a equipe teria certeza que uma modificação em uma função não teria impacto em algum lugar obscuro, muito dificil de testar manualmente?

Em outra realidade eu sou um programador ABAP mediano. Faço TDD e TUDO o que eu desenvolvo possui uma mega suite de testes. 2 anos após a minha saída um grupo de 6 pessoas pegaram os meus testes, javadocs e as wikis cheias de coisa divertida. Eles tem que mudar varias coisas e se sentem seguros pois existe uma entidade que testa o codigo e ja avisa que tem algo estranho. Provavelmente alguns testes terão que ser reescritos mas é facil com os artefatos que eu deixei pra tras.

Provavelmente esse cenário é menos pior do que o outro em termos de manutenção.

Luca:

Olá

aleck:

Diletante: O que se ocupa de qualquer assunto por gosto, e não por obrigação.
Profissional: Pessoa que faz uma coisa por profissão.
Inveja: Sentimento de cobiça à vista da felicidade, da superioridade de outrem

Repare que na minha resposta eu NÃO exclui o profissional que trabalha por prazer que foi sempre o que eu tentei fazer desde que me formei engenheiro em 1970.

E não entendi porque incluiu inveja na sua mensagem. Você acha que alguém faz frameworks por inveja? Ou que eu tenho inveja de quem faz? Explique-se.

[]s
Luca

Eu estava quotando o nadele 8)

Agregando ao post: When TDD goes bad

Eu realmente acho viciante como o Paulo falou ao abrir o tópico. E é aí que mora o perigo, pois testes se tornam validadores de código de alto acoplamento. O pensamento voltado para classes e métodos ao invés aquiescer story cases e cenários específicos, que é o que o cliente (e até mesmo o sistema) espera no fim das contas, vide BDD.