Testando o Inkscape

O Inkscape é um projeto jovem e a ênfase está ainda em adicionar recursos. Ainda assim é gratificante ver que a estabilidade do Inkspace tem sido constantemente aumentada à cada lançamento.

A parte mais importante do ‘Testando’ é simplesmente usar o Inkscape para trabalho normal — confirmando que o Inkscape atingiu esse nível de maturidade, exercitar os novos recursos e verificar se o aplicativo funciona conforme o esperado.

Relate um erro se você encontrar qualquer coisa que não se comportar como deveria. Um relatório de erro deve incluir pelo menos uma descrição passo a passo de como acionar o erro e/ou um arquivo de teste que demonstra o problema (o menor/mais focalizado arquivo de teste é melhor).

Usuários

O campo está aberto. Estamos ansiosos para receber relatórios de erros e solicitações de recursos (sob a forma de um relatório de erro). Estas dos quais muitas vezes exigem análise, esclarecimento e mais ação. Qualquer um pode fazer isso.

Melhor ainda seria fornecer liberações para qualquer parte do aplicativo que não está à altura do que esperam - é a confirmação de que o projeto está evoluindo. Observe que teste sério deve ser feito com uma compilação 'instável', qualquer um que você fez consigo mesmo (veja Compilando o Inkscape), ou um instantâneo que você tenha baixado. Também gostaríamos de ouvir sobre as áreas em que não temos paridade com aplicações comparáveis. Se você achar que você está chegando com ideias interessantes sobre as deficiências no Inkscape, ou planos para seu futuro, envolva-se com o grupo de testadores do Inkscape.

Precisamos de pessoas para criar e atualizar a documentação, ajuda on-line, tutoriais e capturas de tela. Observar defeitos neles é uma forma perfeitamente válida de teste - não queremos lançamentos com documentação obsoleta.

Testadores do Inkscape

Esta seção está desatualizada em sua na maior parte.

Uma comunidade de testadores do Inkscape tem crescido e tem a sua própria lista de discussão, e é de se esperar que isso irá liderar todo o trabalho sobre usabilidade e fatores humanos. Este grupo deve ser seu primeiro porto de escala para estas áreas (alguns dos seguintes links estão mortos):

• Teste de Conformidade
• Teste de Regressão do Inkscape
• Testes de Interoperabilidade
• Teste de Usabilidade
• Teste de Desempenho
• Conformidade de HIG

Veja também a Biblioteca de Testes. Nota: Bryce? Jon? toda essa página não deveria ser mesclada aqui? Ou é melhor ter essa informação em duas partes. IMHO páginas wiki não devem ser feitas.

Testes de Renderização

Esta seção está desatualizada em sua na maior parte.

Notas de su_v:

<su_v> Tavmjong: Johan migrar a suite para o launchpad ... https://launchpad.net/inkscape-rendertest
<su_v> um dos estudantes GSoC IIRC fizeram algum trabalho em 2014, também: https://code.launchpad.net/~penginsbacon
<su_v> (havia alguns posts relacionados no inkscape-devel por Tomasz e por Guiu no ano anterior)
<su_v> https://code.launchpad.net/~neandertalspeople <-- que Guiu estava trabalhando
<su_v> https://sourceforge.net/p/inkscape/mailman/message/32295526/ (a página da web do resultado do teste ainda está lá)

Além disso, o Inkscape tem testes de renderização que não precisam necessariamente de um desenvolvedor para criar, executar e analisar. Os testes reais podem ser encontrados no SVN (veja abaixo). Abaixo você pode encontrar informações sobre como executar e criar estes testes por conta própria.

Veja esta lista para obter resultados atualizados.

Executando testes de renderização

Além de executar testes de unidade de baixo nível do Inkscape também pode ser testado em um nível mais elevado (veja também SVG Suite de Testes de Conformidade). Atualmente (2008-7-26) há uma ferramenta de testes de renderização (juntamente com alguns casos de teste) no SVN, que pode ser usada para automatizar parcialmente testes de renderização.

Para executar os testes de renderização:

• Se necessário, compilar tester.cpp usando ‘g++ -o tester tester.cpp’ (há um .exe pré-compilado por usuários do SVN para Windows).
• Execute o runtests.py. Se necessário você pode especificar o caminho do Inkscape e algumas outras coisas (executar ‘runtests.py --help’ para ver quais opções estão disponíveis).

Observe que por padrão é usada somente uma comparação binária entre os arquivos de saída e referência, perceptualdiff (ou qualquer outra ferramenta de comparação que retorna zero em caso de sucesso e 1 em caso de falha) pode ser usada para auxiliar a comparação de imagens (veja as opções disponíveis de runtests.py). Observe que perceptualdiff (1.0.2) teve alguns problemas com a transparência, isto pode ser resolvidos agora, e se não, existe uma liberação no seu controlador de liberações.

Para selecionar um subconjunto dos testes para executar, especifique um ou mais padrões (com curingas no estilo Unix) na linha de comando. Cada padrão é interpretado como especificando um prefixo. Por exemplo, ‘runtest.py bugs’ corresponderá a quaisquer testes cujo caminho relativo ao diretório com casos de teste começa com ‘bugs’ (por exemplo: ‘bugsy.svg’ ou ‘bugs/bugXYZ.svg’).

Os resultados de teste mais comuns são:

• Pass (o arquivo de saída foi comparado a uma passagem por referência)
• Fail (o arquivo de saída foi comparado a uma falha de referência)
• New (o arquivo de saída não correspondia a qualquer referência)
• No references (não havia nenhuma referência em tudo)

runtests.py coloca os arquivos de saída em um subdiretório ‘output’ (no mesmo nível como os diretórios ‘testcases’ e ‘references’).

Criando testes de renderização

Só colocar um arquivo SVG no diretório ‘testcases’ (subpastas podem ser usadas para organizar os testes).

Para adicionar uma referência de pass/fail, é só colocá-la no local correspondente sob references/pass ou references/fail. As referências são comparadas por prefixo, então qualquer referência que tem o nome original (sem a extensão) como um prefixo é vista como uma referência para esse arquivo.

Referências de falha são usadas para distinguir entre um resultado que é conhecido como errado e um resultado que é só (talvez apenas um pouco) diferente do processamento correto. Se você não tiver habilidade para criar uma referência de passagem, você pode até mesmo dar apenas uma referência de falha.

Também é possível criar um arquivo SVG que deve produzir a exata saída como um caso de teste, mas que usa métodos mais simples (ou diferentes). Esta prática é sugerida como plano de Teste de Conformidade de SVG. Por exemplo, se o arquivo de caso de teste é chamado de ‘testcases/basic/foo.svg’ você pode criar um arquivo “patch” chamado ‘testcases/basic/foo-patch.svg’. runtests.py iria usar o Inkscape para criar um arquivo de passagem  por referência de que (como ‘references/pass/basic/foo-patch.svg’) e usá-lo como uma das referências. (Note que essa referência em geral não deve ser enviada para o SVN.)

Desenvolvedores

Criar relatório

Há um ‘relatório de compilação do Inkscape’; que é enviado regularmente à lista inkscape-tester (e, periodicamente, à lista de desenvolvedores, quando novos problemas são vistos) que dá uma contagem de avisos marcada no código.

• Testes Rápidos
• Defeitos no sistema de compilação

Executando testes unitários

Agora existem alguns testes de unidade que devem ser realizados antes de subir código. Isto podem levar algum tempo para ser concluído, e para que isto não se torne uma exigência para cada compilação (Desenvolvimento Guiado por Testes), não obstante todos devem honrar o compromisso para não ‘quebrar a compilação’ subindo código que não passe nestes testes. Você pode executá-los por:

• Linux: Basta executar ‘make check’, isto irá compilar e executá-las. Ele também deve funcionar no Mac OS X.
• Windows: Use ‘buildtool check’ (onde buildtool é construído usando ‘g++ -O3 -o buildtool buildtool.cpp’) para criar e executar a unidade de testes. Alternativamente, você pode usar dist-all-check para construir tudo e executar os testes de unidade.

Cxxtests irá gerar dois arquivos de resultados (mais ou menos equivalentes), um arquivo XML e um arquivo de texto com a extensão ‘.log’. No Linux, esses arquivos estão localizados em (buildpath)/src.

Criando testes unitários

O Inkscape usa o framework CxxTest. Para melhorar, modificar ou estender os testes de unidade existentes, basta editar o arquivo de teste existente (…-test.h).

A maneira mais fácil de criar um novo teste em um diretório que já tem alguns testes de unidade é simplesmente copiar um dos arquivos de teste existente, tira-lo (remover algo específico e renomear a classe, construtores, etc) e adicionar alguns métodos de teste. Aproveite o tempo para olhar para os diferentes suportes de CxxTest à instruções ASSERT, as variantes TSM_ podem ser especialmente úteis por exemplo quando você quer testar um monte de casos diferentes. Importante: para fazer tudo ser construido de forma correta você tem que fazer o seguinte:

• Adicionar o arquivo ao grupo certo (já existente) no cxxtest no destino build.xml
• Acrescente o arquivo a variável CXXTEST_TESTSUITES em dir/Makefile_insert. Cuidado com as barras invertidas no final das linhas. Note que você tem que prefixar “$(srcdir)/dir/” para o seu nome de arquivo, uma vez que é uma variável normal não tratada pelo Automake, e você tem que usar += ao invés de =, porque você está anexando a essa variável em vez de defini-la.

# Como isto:
CXXTEST_TESTSUITES += \
    $(srcdir)/dir/first-test.h \
    $(srcdir)/dir/second-test.h

Para a criação de uma unidade de teste em um diretório que não tem nenhum teste de unidade:

• Atualizar o sistema de compilação do Windows:
  • Adicionar um grupo de cxxtestpart para o destino de cxxtest no build.xml (apenas copiar e modificar um já existente).
  • Adicione arquivo .o correspondente à lista de exclusão do alvo lib no build.xml e à lista de inclusão do alvo linkcxxtests.
• Para Unix, não são necessárias demais alterações exceto adicionar o arquivo de CXXTEST_TESTSUITES em Makefile_insert.

Executando testes isolados

Para testes de unidade isto não é problema, basta configurar algo que execute cxxtests e você pode usar um dos arquivos de log que ele cria para ver o resultado.

Para ser capaz de executar os testes de renderização autônoma no Windows, você tem que compilar o Inkscape como um executável de linha de comando para impedir que apareçam quaisquer caixas de diálogo de erro em tempo de execução no CRT (ou algo semelhante). Em Linux e em outros Unixes, este problema não existe.

O arquivo teststatus.json que é gerado por runtests.py e contém todos os resultados de testes (no formato JSON). Note que se você executar apenas um subconjunto dos testes este arquivo mantém todas as informações sobre testes que não entraram nesse subconjunto. Ele também retém resultados de testes antigos. Os códigos de resultado neste arquivo podem ser interpretados como em runtests.py (por exemplo, 0, 1 e 2 significam passou, falhou e novo, respectivamente).

Analisando a abrangência de testes

Para ver quão bem os testes (unitários) abrangem certas partes do código, ou para comparar a cobertura dos testes de renderização vs testes unitários, gcov pode ser usado. Consulte Criação de Perfil para obter mais informações sobre como usar o gcov e coverage.py (uma ferramenta para obter um certo controle sobre as enormes quantidades de dados que o gcov pode gerar).