Fpcunit Testcase Para O Acbr

[Daniel Simoes]

Olá pessoal,

 

Realizei um Commit com a primeira versão da FPCUnit Test para o ACBr...  A ideia é escrever Unit Testes para TODO o ACBr... isso será uma tarefa muito difícil, mas com isso iremos aumentar muito a qualidade dos nossos fontes... e conseguiremos testar rapidamente se algo foi quebrado com alguma modificação nos fontes...

 

Talvez precisamos dos mesmos projetos, usando DUnit (para rodar os teste em Delphi)...

 

Sugestões e ajuda na construção de novos TestCases são muito bem vindas...

 

 

 

Que diabos é FPCUnit ?? (Veja esse link)

DUnit

[EMBarbosa]

Eu estava pensando em propor isso pra uma próxima reunião com os devs.

[Daniel Simoes]

Tópico movido para "Dúvidas Gerais"... (para tentar atrair ajuda da comunidade na construção de Test Cases)

[EMBarbosa]

Quem quiser um passo a passo simples, pode ver o seguinte link.

Se houver necessidade de um passo a passo em português com exemplos do ACBr, fiquem a vontade em se pronunciar. Daí eu posso providenciar.

[EMBarbosa]

  Estou compatibilizando os testes atuais com o DUnit. Acredito que isso possa facilitar para que aqueles que não quiserem se aventurar no Lazarus possam ajudar neste sentido.

  Seguindo as sugestões nessa resposta no StackOverflow, fiz as modificações e parece que no momento está tudo ok.

  A maior diferença são alguns IFDEFs que precisam ser adicionados e ao invés de se utilizar AssertTrue, AsserEquals, etc... é preciso utilizar CheckTrue, CheckEquals, etc...

  Isso torna os códigos compatíveis.

 

  A resposta no StackOverflow acima citada, em seus comentários, sugere uma criação de uma classe "wrapper" para facilitar a escrita para os dois testes sem ficar fazendo um monte de IFDEFs no código. Sugestões são bem vindas.

[Daniel Simoes]

Obrigado pela ajuda Elton,

 

Com a ajuda dos novos UnitTestes ficou evidente que temos problemas na TACBrTXTClass... (também será mais simples de corrigi-los)

[Daniel Simoes]

Esses DUnit FPCUnit são uma mão na roda...

 

Apliquei uma correção para o problema de arredondamento do LFILL...

 

Trata-se de um velho problema do Delphi, quando usando Trunc com expressões e não variáveis...  Por sorte na ACBrUtil já existe um método para esse problema... o TruncFix

 

Também notei um pequeno problema nos testes: LFillExtendedSeisCasas_UmBilionesimoDouble_Retorno e LFillExtendedSeisCasas_UmBilionesimoExtended_Retorno

[EMBarbosa]

Também notei um pequeno problema nos testes: LFillExtendedSeisCasas_UmBilionesimoDouble_Retorno e LFillExtendedSeisCasas_UmBilionesimoExtended_Retorno

 

Mas aí o teste passa quando o valor não é nulo.

Estes dois testes específicos não poderiam retornar uma string só com o delimitador mesmo marcando o LFill para nulo, pois "0.000000001 <> 0".

 

Vou tentar verificar onde pode estar o problema...

[EMBarbosa]

Mas aí o teste passa quando o valor não é nulo.

Estes dois testes específicos não poderiam retornar uma string só com o delimitador mesmo marcando o LFill para nulo, pois "0.000000001 <> 0".

 

Vou tentar verificar onde pode estar o problema...

Para não poluir mais esse tópico com o assunto de arredondamento, postei uma explicação para eu não mexer em nada sobre isso neste

[RicardoLara]

Olá Pessoal,

 

Estou criando alguns casos de teste para a unit ACBrUtil com base no exemplo disponibilizado no svn e também em algumas explicações que encontrei na internet. Porém estão acontecendo dois problemas, um creio que possa ser alguma configuração de encoding e o outro creio que seja um possível erro.

 

 

1º- Estou realizando o teste do método ParseText, mas quando é iniciado a comparação das letras acentuadas, a função retorna sempre o caractere "?". Tentei mudar o encoding da página(File Settings -> Encoding) para verificar se o problema poderia ser esse, mas não obtive êxito.

 

2º Realizei um teste com o método SepararDados, em um teste apenas fiz a abertura da tag e não fechei, o método retornou vazio que imagino ser o retorno esperado. Em seguida, realizei o mesmo teste mas ao invés de abrir a tag e não fechar, eu não realizei a abertura e apenas fechei. Mas aconteceu um erro, conforme pode ser visto na imagem anexada. Creio que ele deveria retornar vazio, como foi retornado no primeiro caso de teste citado.

 

Anexado Imagem da tela do FPCUnit para melhor compreensão.

 

Disponibilizado projeto feito para melhor compreensão em:

https://www.dropbox.com/s/a0was4r3npxl0rr/ACBrComum.7z?dl=0

 

 

Obrigado pela atenção

 

 

att,

 

Ricardo

 

 

[EMBarbosa]

Olá Pessoal,

 

Estou criando alguns casos de teste para a unit ACBrUtil com base no exemplo disponibilizado no svn e também em algumas explicações que encontrei na internet. Porém estão acontecendo dois problemas, um creio que possa ser alguma configuração de encoding e o outro creio que seja um possível erro.

 

 

1º- Estou realizando o teste do método ParseText, mas quando é iniciado a comparação das letras acentuadas, a função retorna sempre o caractere "?". Tentei mudar o encoding da página(File Settings -> Encoding) para verificar se o problema poderia ser esse, mas não obtive êxito.

 

2º Realizei um teste com o método SepararDados, em um teste apenas fiz a abertura da tag e não fechei, o método retornou vazio que imagino ser o retorno esperado. Em seguida, realizei o mesmo teste mas ao invés de abrir a tag e não fechar, eu não realizei a abertura e apenas fechei. Mas aconteceu um erro, conforme pode ser visto na imagem anexada. Creio que ele deveria retornar vazio, como foi retornado no primeiro caso de teste citado.

 

Anexado Imagem da tela do FPCUnit para melhor compreensão.

 

Disponibilizado projeto feito para melhor compreensão em:

https://www.dropbox.com/s/a0was4r3npxl0rr/ACBrComum.7z?dl=0

 

 

Obrigado pela atenção

 

 

att,

 

Ricardo

Adicionei seus tests cases com alguma alteração. Abaixo as considerações até agora:

 

1) O que acontece neste caso é que como estava sendo utilizado os parâmetros padrões, o ParseText estava tentando voltar o valor para UTF8. Isso gerava problema. Fiz uma correção para os testes.

 

2) Acho que outra pessoa que está mais familiarizado com esses métodos poderá lhe explicar melhor qual o comportamento esperado.

 

Então ficaram dois pontos pendentes nos testes.

[RicardoLara]

Obrigado pela resposta Elton.

 

Fiz mais alguns tests cases, vou anexar aqui para que você possa adicionar aos fontes.

 

Obrigado.

 

 

acbrutiltest.zip

Editado 15 Janeiro, 2015 por RicardoLara

[EMBarbosa]

Vou subir as adições.

Vi que você mudou os nomes de alguns testes.

Você acha que assim fica mais claro?

Pessoalmente, eu preferia o jeito anterior.

 

EDIT: Já foi pro SVN.

[EMBarbosa]

Os problemas apresentados nos métodos StringToFloat e StringToFloatDef são na verdade de comparação. Parecidos com o que foi levantado antes nos métodos DFill e LFill. Fiz uma alteração no teste StringToFloatDefTest.Normal para poder mostrar isso. Dê uma olhada.

 

EDIT: Revisão 8169. Também modifiquei ara adicionar a vírgula na string visto que este método serve exatamente para isso. (:

 

Outra coisa, o método StrIsAlpha não considera acentos como sendo Alpha. Se verificar o código vai perceber. Então acho que basta modificar o teste StrIsAlphaTest.TextoComCaractersAcentuados para CheckFalse.

[RicardoLara]

Vou subir as adições.

Vi que você mudou os nomes de alguns testes.

Você acha que assim fica mais claro?

Pessoalmente, eu preferia o jeito anterior.

 

EDIT: Já foi pro SVN.

 

Então, olhando depois me parece que ficou repetitivo, mas mudar foi apenas uma sugestão. Veja como é melhor.

[RicardoLara]

Os problemas apresentados nos métodos StringToFloat e StringToFloatDef são na verdade de comparação. Parecidos com o que foi levantado antes nos métodos DFill e LFill. Fiz uma alteração no teste StringToFloatDefTest.Normal para poder mostrar isso. Dê uma olhada.

 

EDIT: Revisão 8169. Também modifiquei ara adicionar a vírgula na string visto que este método serve exatamente para isso. (:

 

Outra coisa, o método StrIsAlpha não considera acentos como sendo Alpha. Se verificar o código vai perceber. Então acho que basta modificar o teste StrIsAlphaTest.TextoComCaractersAcentuados para CheckFalse.

 

Ok, vou olhar sim. Obrigado.

[RicardoLara]

Boa tarde,

 

Segue arquivo atualizado com mais testes.

 

 

acbrutiltest.zip

[EMBarbosa]

Boa tarde Ricardo.

 

Mais uma vez muito obrigado pelas contribuições. Já está disponível no SVN.

[EMBarbosa]

Então, olhando depois me parece que ficou repetitivo, mas mudar foi apenas uma sugestão. Veja como é melhor.

A princípio eu também tinha achado, mas no DUnit não fica tão claro. Veja as seguintes imagens:

 

Não dá pra saber exatamente porque falhou o teste, de qual classe ou método é o teste, nem o que esperar. Se houver mais de um teste com o mesmo nome então é que fica confuso mesmo.

 

Como estamos adicionando os testes por agora, acho que seria um bom momento para definirmos um padrão para nomenclatura dos testes. Afinal, como diz uma frase famosa:

 

Há apenas duas coisas difíceis em computação, invalidar cache, nomear coisas e erros ao contar.

 

Fiz uma pequena pesquisa sobre o assunto, e parece que o mais aceito é que:

 

O nome do teste deve:

1. ser curto, mas descritivo o suficiente para identificá-lo mesmo por quem não está acostumado com os testes;
2. descrever, se possível, a ação, o estado do objeto testado e o objetivo do teste;
3. descrever o resultado esperado;

Isso basicamente é conseguido seguindo o padrão:

[unidadeDeTrabalho_EstadoSendoTestado_ResultadoEsperado]

 

Neste caso, unidade de trabalho pode ser um método, classe ou várias classes. Mas representa o que está sendo testado neste teste específico. No entanto, deve-se tomar cuidado ao incluir o nome do método no teste caso exista alguma possibilidade de este método ser renomeado depois.

 

Estado sendo testado descreve as condições do teste ou ação.

 

Isso sugere nomes como:

   WEBServer_LoginComSenhaVazia_DeveFalhar

   WEBServer_LoginComUsuarioVazio_DeveFalhar

   WEBServer_LoginComSenhaeUsuarioVazios_DeveFalhar

   Soma_NumeroNegativoNo1oParametro_GeraException

   Soma_ValoresSimples_SaoCalculados

 

As classes de teste podem ser nomeadas com o nome da classe e o sufixo Testes (ou Tests) por exemplo:

[NomeDaClasseTestes]

 

Se todos concordarem, podemos definir esse padrão. O que acham?

 

Algumas das fontes que eu consultei:

https://stackoverflow.com/questions/155436/unit-test-naming-best-practices

http://osherove.com/blog/2005/4/3/naming-standards-for-unit-tests.html

http://testing.bredex.de/naming-conventions-for-test-cases.html

https://code.google.com/p/robotframework/wiki/HowToWriteGoodTestCases#Test_case_names

http://sysgears.com/articles/the-art-of-writing-effective-and-transparent-test-cases/

[RicardoLara]

Olá Elton,

 

Realmente creio que é o melhor a ser feito, ficará muito bom.

[Daniel Simoes]

Muito bom... de acordo Elton...