Importancia de um bom TestCase !

[dardevelin]

Boas, tenho visto vários pedidos de ajuda muito dispersos, isto não é bom por varias razões portanto decidi criar este Post a ver se há algo que possamos fazer quanto a isso.

Antes de podermos "consertar" seja o que for é necessário saber identificar o problema,

1. Muitas duvidas em um só post.

Tentar resolver varias duvidas em um só post é útil a primeira vista, uma vez que assim as pessoas não assumem que sabemos X ou Y, e dão-nós uma explicação mais abrangente ao problema que queremos resolver.

Tal método é também útil quando queremos ter alguma opinião sobre uma decisão de design de software, visto que uma API, estrutura de uma biblioteca ou pedaço de código são materiais para serem usados por outros programadores, cujo o seu feedback é importante.

Mas vamos dar uma vista de olhos as contra partidas.

- Post torna-se demasiado extenso de uma forma justificável. Incentiva o desleixo e o "bitaite". Porquê ?

Os programas usam abstracções lógicas. Cada programador tem uma abordagem a resolução de certos problemas, isto significa que quem fornece ajuda tem liberdade de dizer "Eu não faria da forma Y, mas antes da forma Z->Y->X. Ora se o objectivo principal for resolver X, mudar a abordagem não é aquilo que desejava-mos.

Um bom contra argumenta teria como base de que, por vezes a abordagem sugerida pelo outro individuo é melhor que a nossa, contudo eu contra argumento o "contra argumento" dizendo que, se é uma questão é de design, então deveria estar identificada como tal, onde portanto faria sentido realizar varias perguntas, pois o intuito é mesmo obter varia direcções/modelos aplicáveis, o que nesse caso, exclui-se do género de perguntas orientadas a X.

Posts Dispersos originam perguntas dispersas, perguntas dispersas desvalorizam o post, tornam-o especifico o suficiente para não servir para outro problema. No meu ver isto é que faz com que a base de conhecimento gerada no forum não sirva como referência.

- O facto que não podemos usar a base de conhecimento gerada no forum faz com que os membros tenham menos paciência e criem respostas menos rigorosas levando a más praticas ou ao não entendimento daquilo que se esta a tentar resolver.

- Duplicam-se esforços sobre o mesmo problema e acaba por não se dar espaço para novas ideias.

Outro problema que tenho visto com alguma regularidade é a falta de cuidado ao criar um testcase.

O que é um testcase ?

Uma porção de código pequena, não muito relativa ao nosso programa que demonstre explicitamente a nossa duvida.

Esta porção de código tem de ser completa, no sentido de que, inclui tudo o que é necessário para, compilar e executar o código nas maquinas de quem pretende fornecer ajuda.

Se o código fornecido não compila, já falhou como testcase.

Os compiladores emitem avisos e erros, são para ser usados. Devemos recorrer a ajuda de outros membros quando é uma falha no processo lógico, se a falha é de compilação então é nossa obrigação pesquisar para assim aprender a ler os erros fornecidos pelo compilador, perguntar não gera conhecimento, visto que não nos fornece a pratica necessária na leitura destes erros.

Eu até chego a argumentar que, irão por muitas das vezes resolver e encontrar soluções aos problemas durante a criação do testcase.

Portanto o que não fazer: Longos pasts de código, não são úteis. Dizer que o programa "estoira" nada explica sobre o problema. Tenho visto o pessoal dizer,

- Tenho o programa X que é suposto fazer Y, ate aqui tudo bem. < tudo bem o que ?

- Ele executa ate aqui - colam todos erros, ou pior nenhum, atiram um palpite, podem ajudar-me, colam o código de vários ficheiros no geshi.

Será que apenas eu vejo isto como um mau sinal ?

Quem quer ser ajudado tem de ajudar começando por:

1º Encontrar o seu verdadeiro problema/ duvida.

2º Ser conciso e directo quando expõe a duvida.

3º Apresentar o que já foi testado para evitar duplicação, se necessário apresentar pasts, digamos em um ideone ou codepad com o testcases que compravam essas mesmas experiências. Conter no testcase o resultado observado e expor o que continua a causar duvida em tal cenário.

4º Procurar enquanto os outros não respondem.

5º Iterar pelo código manualmente, a sério não é assim tão incomum pegar em um papel e caneta e tentar correr o código que escreveram passo a passo.

Isto esta a torna-se longo, mas já deu para colocar os pontos principais.