Obrigado pelo comentário.

É verdade.
Teste de unidade é algo presente em todos os livros de teste, em todas as ementas de certificações, no vocabulário das universidades e em vários outras fontes de conhecimento relativas a teste de software, mas infelizmente não é parte do dia a dia da maioria dos desenvolvedores, gerentes, engenheiros de software das nossas empresas.

Tanto que pra muitos é um mito, um trabalho em dobro, um esforço sem retorno ou algo extremamente complexo, quando na verdade não é.
O objetivo aqui é desmistificar um pouco dessa atividade que pode economizar muito do nosso tempo e esforço. Em futuras publicações vou tentar falar mais sobre os aspectos gerenciais do TDD com alguns exemplos mais complexos usando o JUnit.

Abraços.

Muito interessante este artigo!
Lembrei da época da universidade, quando tive o primeiro contato com o TDD…
É incrível como não “damos bola” a técnicas relativamente simples, mas de grande valia como essa em questão.

Parabéns pelo artigo!

Esse é um tema para ser discutido mais vezes!

É um enorme prazer ter você comentando aqui no BugBang. Primeiramente, muito obrigado pelo comentário.

Muito obrigado também pelas críticas e pelos elogios. E sim, o principal intuito aqui é me fazer pesquisar, estudar e ajudar quem também está em busca de algum conhecimento, portanto, as críticas são muito bem vindas sempre

O objetivo principal do post era demonstrar de uma forma mais simples e prática como podemos desenvolver testes de unidade e como eles podem nos ajudar a evitar problemas em implementações relativamente simples, talvez como um acompanhamento do post comentado do Quezada no lado “Java da força”.

Como você sabe, os testes de unidade ainda são uma prática longe de ser reconhecida como amplamente abordada nas empresas de software (principalmente no Brasil), em função de vários mitos como o do trabalho dobrado ou o do gap entre os testes e os fontes (ótimamente desmistificado pela metáfora do seu comentário).

Nesse caso, não queria preencher inúmeras linhas falando sobre o que uma rápida pesquisa no Google poderia proporcionar, ou sobre o que vemos nas salas das nossas universidades, mas sim sobre uma forma simples, com um cenário conhecido e com um exemplo passo a passo, de forma a incentivar a prática dessa técnica.

Outra coisa importante. Eu não sou um profundo conhecedor do mundo ágil, embora esteja gastando boa parte do meu tempo a estudos nos últimos meses, e possivelmente, em futuros posts sobre o assunto poderemos ver um pouco do amadurecimento nessas práticas fantásticas e inovadoras, além é claro, de outros pontos a serem contrariados assim como os desse post.

Mais uma vez muito obrigado. Suas críticas já estão me orientando a buscar novos conhecimentos

Abraços.

Cheguei aqui a partir de um twit do Fabricio (QualidadeBR), e estou comentando no seu blog pela primeira vez.

Não é muito simpático estrear os comentários colocando uma crítica, principalmente quando se percebe que foi feito com seriedade e está muito bem escrito. Mas acho que a discussão de ideias é o objetivo principal de um blog.

A principal crítica é a seguinte: não foi abordada aqui a premissa dos passos de bebê (baby steps). O tamanho dos testes apresentados e do código de produção é muito grande. Deveria ser uma assertiva por ciclo, não uma classe por ciclo.

Gostei da figura, reflete bem a técnica, mas a escala de tempo/tamanho do código em TDD é bem menor. A metáfora que costumo usar é a do velocista deficiente visual: a escrita dos testes (o atleta guia que enxerga) vão na mesma velocidade que a escrita do código (o atleta que compete).

Outra questão: “ter todos os requisitos especificados e detalhados” não me parece um pré-requisito, mas uma sina. Quando vejo requisitos muito detalhados, fico com uma pulga atrás da orelha: geralmente são produto de especulação. Infelizmente, é essa a regra quando se trabalha no modelo de fábrica.

É escrevendo exemplos (também conhecidos como testes) que conseguimos esclarecer e detalhar o que se espera ser desenvolvido.

Espero ter contribuído,

Jorge Diz
twitter: @jorgediz

Vamos repassar, pois este orgão jamais nos ajudou e está fazendo jogo político:

http://zarroboogsfound.blogspot.com/2010/03/sindpd-esta-defendendo-quem-fere-o.html

Obrigado!

Fico feliz em saber que outras pessoas compartilham do hábito de ler livros que tem uma década a mais que a própria idade haha. Apesar de ser um exemplo de 79, o exemplo do triângulo é um dos melhores até os dias de hoje.

Abraços e obrigado novamente pelo excelente comentário!

Vê o exemplo clássico do triângulo (utilizado pelo Glenford Myers na primeira edição do “The Art of Software Testing”, isso em 1979!), foi como vê a versão resmaterizada de um filme.

Quando se fala em TDD, é importante lembrar que ele é sobre modelar/projetar a funcionalidade. Os testes (a princípio) são apenas um meio, não o fim.

Depois que a funcionalidade já estiver pronta, os testes que até então só foram feitos para nos ajudar na modelagem da funcionalidade, acabam sendo usados como testes de regressão e ajudam o desenvolvedor a ter ciência sobre a qualidade do código e se as mudanças realizadas não quebraram nada.

Ou seja, TDD nos ajuda antes (entendendo melhor a funcionalidade a ser desenvolvida), durante (implementando de forma ciente [nada de eu acho] e testável a funcionalidade) e depois do desenvolvimento (garantindo a qualidade da funcionalidade).

Parabéns Camilo!

Abraços!

Realmente. Unit Test é outra “cabeça de bacalhau” da nossa área, assim como automação de testes funcionais, automação de testes de carga e estresse, modelo V, inspeções, análise de caixa branca e etc.

Todo mundo sabe (ou diz) que é importante, mas quase ninguém implementa. Ou por falta de conhecimento, ou por achar muito complicado ou mesmo por não acreditar nos benefícios e economia que essas técnicas agregam aos nossos projetos de desenvolvimento de software.

Por isso é tão importante que existiram mais publicações técnicas sobre esses assuntos, desmistificando-os, alinhando conceitos sobre as atividades de teste de software e retirando aquela visão errônea que o testador tem menos conhecimento do que o desenvolvedor.

Muito obrigado pelo comentário e atenção.
Abraços.