Testar um pouco é melhor do que não testar nada

Alberto Saviola enviou um texto para o Artima onde ele fala que nem todos os desenvolvedores estão prontos, tem condições ou vontade de "cair de cabeça" nos testes, mas como as metodologias ágeis levam os testes como religião e dizendo que ou você testa tudo ou não testa nada, essas pessoas que ainda não foram "infectadas" pelos testes terminam achando que já que não vão testar tudo, então não se testa nada.

Texto completo: Testivus - Testing For The Rest Of Us

É claro que deve-se dar um passo de cada vez, incutir uma cultura de testes de software em uma equipe ou em um processo que não prevê esse tipod e abordagem dá trabalho e deve ser feito com calma, mas isso também não pode ser visto como motivo pra ficar sempre fazendo teste "do que é importante". A idéia é subir até o todo da montanha e não montar um acampamento na base dela.

Hahaha, muito bom! Coincidentemente tivemos uma reunião no início da semana aqui na empresa onde o assunto foi semelhante a parte do que está escrito nesse post!!!

Show de bola Mauricio!

Veja como exemplo a gente, aqui na Siemens.

Temos um perfil de aplicação muito diferente do que se vê nos livros por aí. São aplicações que fazem uso intensivo de threads e sockets para interagir com centrais telefônicas, de comportamento complexo.

As classes core desse tipo de aplicação não só são multi-threaded, como também devem lidar com questões como sincronização com as centrais, diferenças de timers, etc.

Agora, vai montar JUnit para elas!! É praticamente impossível. Muitas vezes só isso é suficiente para desgostar os T1, desmotivar totalmente os T2 e colocar os T3 com um sonoro "eu falei que isso não prestava" na boca.

Entretanto, isso não significa que para todo o resto do sistema não deve haver testes. Bem pelo contrário. Todo local onde pode haver teste unitário, há. As classes core, onde isso é mais custoso do que o benefício gerado, são cobertas por extensivos testes funcionais.

É mesmo muito importante testar sempre. Mesmo quando você ainda não tem capacidade ou recursos de fazer o teste, testar o que pode ser testado. E ficar atento, pois um dia, pode surgir algo que viabilize o teste daquilo que você pensava não ser possível.

Vou pegar uma carona neste tópico. Com licença.

Eu não uso testes, e me sinto mal por isto.
Em meus sistemas, o usuário digita dois ou três parâmetros, o programa vai ao banco de dados e gera um pdf. Vou testar o que, se praticamente não há processamento do tipo calcula isto, aquilo etc ... ? Os parâmetros são testados no front-end. Como testar os selects ? Testar a geração de um PDF (iText) ?

Agradeço por comentários,

Márcio

Os parâmetros são tratados, não são? Então o tratamento deles deve ser testado. De resto, se a situação é tão simples assim, não tem muita coisa, mas as coisas nem sempre são tão simples, né?

Temos um perfil de aplicação muito diferente do que se vê nos livros por aí. São aplicações que fazem uso intensivo de threads e sockets para interagir com centrais telefônicas, de comportamento complexo.

As classes core desse tipo de aplicação não só são multi-threaded, como também devem lidar com questões como sincronização com as centrais, diferenças de timers, etc.

Agora, vai montar JUnit para elas!! É praticamente impossível. Muitas vezes só isso é suficiente para desgostar os T1, desmotivar totalmente os T2 e colocar os T3 com um sonoro "eu falei que isso não prestava" na boca.

Isso é verdade. Eu trabalhei durante um tempo com sistemas deste tipo quando trabalhava numa empresa que vende soluções VoIP com Asterisk.

É muito difícil fazer testes com esse tipo de plataforma, mas aí eu acho que deve prevalecer a regra: "Testes imperfeitos executados frequentemente são muito melhores do que testes perfeitos que sequer são escritos".

Eu nunca ví nenhum sistema por mais testável que fosse com 100% de cobertura de testes. Se mesmo com sistemas complexos for possível cobrir qualquer coisa, já é melhor do que nada.

A cultura de testes pode até ser útil para que as pessoas passem a programar as coisas de forma mais "testável" utilizando por exemplo Dependency Injection, separando melhor as camadas da aplicação, etc.

ViniGodoy wrote:As classes core desse tipo de aplicação não só são multi-threaded, como também devem lidar com questões como sincronização com as centrais, diferenças de timers, etc.

Agora, vai montar JUnit para elas!! É praticamente impossível. Muitas vezes só isso é suficiente para desgostar os T1, desmotivar totalmente os T2 e colocar os T3 com um sonoro "eu falei que isso não prestava" na boca.

Pois eu acho que não. Trabalho com transações bancárias em servidores multithread que estão sempre enviando e recebendo informações de N clientes e nós pegamos MUITOS bugs de threading fazendo testes com o JUnitPerf. Não posso dizer que estamos livres de problemas, mas muita coisa já foi descoberta e resolvida com os nossos testes e isso nos dá segurança pra continuar no caminho certo.

Acho que nós devemos sempre cobrar dos "gerentes" (se é que dá pra chamar esse povo assim...) de que os testes são uma das partes mais importantes do desenvolvimento. Não podemos simplesmente pensar no curto prazo e deixar os testes pra lá, porque um dia a coisa estoura.

Quanto mais se fuçar no software, melhor, seja do jeito que for.

Sempre pensei assim, entretanto as vezes meu chefe me manda parar.

Eu aprendi a ser fanático com o cv (oops): como você tem certeza que seu código funciona se você não testa ele?

Maurício Linhares wrote:Pois eu acho que não. Trabalho com transações bancárias em servidores multithread que estão sempre enviando e recebendo informações de N clientes e nós pegamos MUITOS bugs de threading fazendo testes com o JUnitPerf. Não posso dizer que estamos livres de problemas, mas muita coisa já foi descoberta e resolvida com os nossos testes e isso nos dá segurança pra continuar no caminho certo.

Garanto à você que não é a mesma coisa. Não vou entrar no quesito dos por quês pois não é o objetivo desse forum. Ainda sim, como eu mesmo ressaltei, ainda procuramos testar essas classes indiretamente, através de testes funcionais.

JavaChild Membro desde: 28/09/2004 18:53:15 Mensagens: 111 Offline

Olá Marcio,

marcioa1 wrote:
Como testar os selects ?

para testes de banco de dados você pode utilizar o dbUnit

marcioa1 wrote:
Testar a geração de um PDF (iText) ?

e para testar classes que dependam de outros objetos você pode dar uma olhada no EasyMock, há uma matéria na JavaMagazine sobre isso

sunshine wrote:Olá Marcio,
e para testar classes que dependam de outros objetos você pode dar uma olhada no EasyMock, há uma matéria na JavaMagazine sobre isso

jmock jmock...

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