Estratégias de testes

[edusantana]

Podemos discutir as estratégias de testes aqui?

[edusantana]

Minhas recomendação seria a seguinte:

• Separar testes de formatação e de texto.
• Criar um arquivo separado para testar cada coisa.

Por exemplo, eu tenho um teste que converte esse arquivo Markdown para esse código em latex.

Dessa forma, fica fácil de saber o que está dando certo ou errado.

Você tem experiências com quais linguagens de programação?

Eu posso auxiliar a fazer um teste em ruby que ler arquivos de um diretório, realiza uma compilação e compara o resultado com outro arquivo contendo o resultado esperado.

Você já utilizou TDD antes?

[edusantana]

Eu não entendi pq o teste está falhando no travis:

$ export PATH=$PATH:/usr/local/texlive/2017/bin/x86_64-linux
0.01s$ sudo tlmgr update --self --all
sudo: tlmgr: command not found
The command "sudo tlmgr update --self --all" failed and exited with 1 during .

[dbmrq]

Não entendi… sua sugestão é continuar usando o método atual pra testar a formatação, mas adicionar outro teste só pro texto? Não entendi qual seria a vantagem, já que o teste atual já checa tanto a formatação quanto o texto.

---

Edit: E reforçando o que eu disse antes, nós queremos que a aparência das referências esteja de acordo com a aparência exigida pela ABNT. Então não importa o que está no texto. O caractere é, por exemplo, pode ser impresso como um combining character ou como um composite character:

Technically, é (U+00E9) is a character that can be decomposed into an equivalent string of the base letter e (U+0065) and combining acute accent (U+0301).

Se compararmos o texto, o teste pode falhar, já que ele é diferente, embora a aparência seja "é" em ambos os casos. O teste atual não liga pra isso. Se o usuário lê "é" e a aparência tem que ser a de "é", tudo certo, não importa como esse "é" foi feito. E pode ter muitos outros exemplos. O LaTeX trata os espaços de jeitos doidos, por exemplo. Não sei o que o BibLaTeX faz por traz das câmeras, mas não é difícil imaginar que um mesmo espaço seja ora produzido com ~ e ora produzido com \hspace{3pt}, por exemplo. O teste falharia, porque o texto é diferente nos dois casos, mas a aparência é a mesma, não importa se o espaço foi produzido de um jeito ou de outro. E pode haver muitos outros exemplos que eu nem consigo conceber, o ponto é que não vejo porque testar o texto, que não interessa, quando podemos testar a aparência, que é o que precisa ser testado (e já está sendo).

[edusantana]

Olha esse teste

Ele informa: given an entry with missing commas between fields, então o comportamento esperado é raises a parser error.

Quando a gente utiliza os testes num projeto ele serve como uma documentação viva do sistema, ele é mais atual e concreto que os manuais, que podem estarem defasados. Muitas vezes eu consulto os testes das bibliotecas para aprender como usar determinadas funcionalidades.

Por isso que eu perguntei a você qual a linguagem de programação que tem experiência e se já utilizou TDD em algum projeto.

Quando a gente escreve os testes antes, isso agiliza o desenvolvimento. Pois evita que fiquemos verificando manualmente se a funcionalidade foi implementada corretamente ou não.

Quando os testes são bem feitos, eles guiam o desenvolvimento da funcionalidade, eles auxiliam a pensar na solução do problema, de tal forma que, mesmo que se os arquivos de testes fossem perdidos, a criação deles permite a pensar na solução de uma forma melhor.

Mas fique a vontade, faça do jeito que preferir.

[dbmrq]

Ah, eu achei que você estava falando de só comparar o texto com um texto de referência, o que não me parece vantajoso em comparação com o que já está sendo feito.

Pelo que eu entendi agora, o que você está propondo é tipo um unit test mesmo, descrever o comportamento esperado independentemente de exemplos concretos, e fazer isso para cada característica esperada. É isso?

Nesse caso eu entendo as vantagens, mas me parece inviável no caso do biblatex-abnt, além de um pouco overkill. Eu não teria a menor ideia de como fazer isso. Mas se você conseguir fazer e estiver afim eu topo ajudar como puder. Pode ser só ignorância minha mesmo.

Quanto às linguagens de programação com que tenho experiência, nada muito relevante, rs. Principalmente Swift e um pouco de Objective-C. Fora isso só quebro um galho com um pouco de tudo. E entendo a ideia do TDD, mas nunca usei de verdade num projeto.

[edusantana]

Antes de você for implementar algo novo, ou realizar alguma correção, cadastra um issue e me explica a funcionalidade que eu tento escrever o teste antes, para você ter essa experiência.

[dbmrq]

Legal, acho que por enquanto não tem muito o que implementar de novo, mas a próxima atualização do BibLaTeX deve quebrar alguma coisa, pra variar, aí eu te aviso, rs.

[dbmrq]

@edusantana Acabei de adicionara a nova opção comp ao estilo numérico… eu não falei com você primeiro porque um usuário estava precisando dessa função (https://github.com/abntex/abntex2/issues/194) e eu quis enviar a atualização o quanto antes. Mas o estilo numérico inteiro não tem teste nenhum, por enquanto eles só cobrem os estilos abnt e abnt-ibid. Então pode ser um lugar interessante pra começar.

Um teste para essa nova opção, por exemplo, teria que ver se com ela a numeração é abreviada (1–4) e se sem ela a numeração é impressa por extenso (1, 2, 3, 4).

E isso é só a última coisa que eu adicionei, mas o ideal seria testar inclusive o básico, como a citação ficar entre parênteses (em vez de colchetes, como é no estilo numeric normal), múltiplas citações serem separadas por vírgulas (em vez de ponto e vírgulas) e por aí vai.

Se estiver afim de olhar isso e eu puder ajudar me avisa. :)

[edusantana]

@dbmrq ok. Eu vou fazer um esboço de uma proposta. Como atualmente eu trabalho mais com ruby, vou fazer a proposta dos com essa linguagem.

Ela envolverá o uso do cucumber, pois ajudaria os usuários a compreender a utilização e configuração.

[edusantana]

Referência que estarei utilizando:

• http://shipit.resultadosdigitais.com.br/blog/estruturando-seu-projeto-com-bdd-e-cucumber/
• https://medium.com/agile-vision/starting-with-bdd-for-collaborative-development-in-agile-environments-5fb034078b3c

• Cucumber features should drive the implementation, not reflect it.
• Cucumber is not a tool for testing software. It is a tool for testing people’s understanding of how software (yet to be written) should behave.

[edusantana]

$ cucumber --i18n-keywords pt

  | feature          | "Funcionalidade", "Característica", "Caracteristica"                                         |
  | background       | "Contexto", "Cenário de Fundo", "Cenario de Fundo", "Fundo"                                  |
  | scenario         | "Cenário", "Cenario"                                                                         |
  | scenario_outline | "Esquema do Cenário", "Esquema do Cenario", "Delineação do Cenário", "Delineacao do Cenario" |
  | examples         | "Exemplos", "Cenários", "Cenarios"                                                           |
  | given            | "* ", "Dado ", "Dada ", "Dados ", "Dadas "                                                   |
  | when             | "* ", "Quando "                                                                              |
  | then             | "* ", "Então ", "Entao "                                                                     |
  | and              | "* ", "E "                                                                                   |
  | but              | "* ", "Mas "                                                                                 |
  | given (code)     | "Dado", "Dada", "Dados", "Dadas"                                                             |
  | when (code)      | "Quando"                                                                                     |
  | then (code)      | "Então", "Entao"                                                                             |
  | and (code)       | "E"                                                                                          |
  | but (code)       | "Mas"                                                                                        |

[edusantana]

Extensão para habilitar destaque de sintaxe do código: https://github.com/alexkrechik/VSCucumberAutoComplete/

[dbmrq]

Legal, obrigado! 🎉

Aproveitando que você está no embalo, vou abrir uma issue no repositório do AbnTeX3 com algumas ideias, dá uma olhada lá.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[edusantana]

@dbmrq eu fiz os testes com o cucumber e aruba para o pandoc_abnt, olha como ficou a especificação.

E ela é executável, se tiver algum problema podemos encontrá-lo mais rápido.

[GuilhermeHideki]

@dbmrq eu fiz os testes com o cucumber e aruba para o pandoc_abnt, olha como ficou a especificação.

E ela é executável, se tiver algum problema podemos encontrá-lo mais rápido.

Desculpa me intrometer e ser um pouco off-topic, mas acredito que os features poderiam ser feitos com as palavras chaves e conteúdo em português (# language: pt-br no começo).

[edusantana]

Desculpa me intrometer e ser um pouco off-topic, mas acredito que os features poderiam ser feitos com as palavras chaves e conteúdo em português (# language: pt-br no começo).

Pode sim :+1: mas o aruba não tem os passos traduzidos em português.

Daí eu teria que reescrever esse passo em português. Como eu tava com outros prioridades, deixei assim mesmo rs.

@GuilhermeHideki fica o convite caso deseje implementar esses passos em português, seria ótimo! :+1: São apenas três passos que utilizo.

[GuilhermeHideki]

@GuilhermeHideki fica o convite caso deseje implementar esses passos em português, seria ótimo! 👍 São apenas três passos que utilizo.

Infelizmente não tenho como fazer isso por enquanto, mas pesquisei e deixei uma possível sugestão na sua issue https://github.com/limarka/pandoc_abnt/issues/24.

[dbmrq]

@edusantana Obrigado! Eu ainda não aprendi a usar o cucumber e estes dias estão bem corridos, mas vou dar uma olhada assim que possível. Vou deixar esta issue aberta pra me lembrar. Enquanto isso, qualquer ajuda pra implementar os testes no biblatex-abnt é muito bem vinda. :)

[edusantana]

Me mostra um exemplo mínimo que podemos usar para testar.

Quando uso tal código... espero tal resultado. Qual o código mínimo e qual comando você utiliza?

[edusantana]

Vou salvar essas referencias aqui...

https://tex.stackexchange.com/questions/12067/whats-the-folk-lore-on-automatic-testing-of-tex-programming https://github.com/raphink/moderntimeline/blob/master/.travis.yml https://tex.stackexchange.com/questions/42328/testing-framework-api-for-latex https://tex.stackexchange.com/questions/38978/how-can-i-manually-install-a-latex-package-debian-ubuntu-linux

[edusantana]

Enviei o código para a branch test, dá uma olhada lá.

Eu acho que ficou legal o build no travis.

Depois você dá um rake relish para publicar as features, como no pandoc_abnt.

[edusantana]

Por fim, não pense em testes como o meio de mostrar que o programa faz o que é esperado, pense em testes como se fosse a Especificação do sistema. A especificação informa como o sistema deve funcionar E o porque ele deve funcionar dessa forma, conforme mostrei aqui

Você também poderá adicionar os testes para comparar itálico e cores, mas recomendo que faça depois da verificação do conteúdo. O ideal é que quando um teste falhe, você saiba a razão do porque ele está falhando.

[dbmrq]

Legal, muito obrigado!

Agora está bem corrido, mas assim que eu puder vou dar uma olhada e tentar trabalhar na especificação.

Quanto a exemplos, acho que podemos usar os testes atuais.

Este é o arquivo que imprime as citações: https://github.com/abntex/biblatex-abnt/blob/master/tests/NBR10520-2002.tex

E este é o resultado esperado: https://github.com/abntex/biblatex-abnt/blob/master/tests/NBR10520-2002_reference.pdf

Então é só decompor em cada exemplo específico. O primeiro caso seria:

A ironia seria assim uma forma implícita de heterogeneidade mostrada, conforme a classificação proposta por \textcite{authier1982}.

Que deve imprimir:

E assim por diante.

[edusantana]

Vamos lá... agora que você entendeu como fazer os testes, precisa compreender como utilizá-lo efetivamente.

Primeira mudança: pense em testes como especificação. O que cada teste revela sobre o sistema? Isso precisa ser descrito em cada teste.

Segunda mudança: escrever a especificação antes da implementação.

Agrupar os testes através de tags, para facilitar a execução.

Quando estou implementado algo novo eu adiciono a tag @wip (work in progress) nos cenários e outra referente a categoria, por exemplo @cite ou @bibliografia.

Então eu executo bundle exec cucumber --tags @wip. Quando os testes estão passando, eu removo o @wip e submeto as alterações pro github.

[dbmrq]

Legal, vou tentar! Muito obrigado pela ajuda. :)

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[edusantana]

@dbmrq eu gostaria da sua autorização para atualizar a estrutura de testes para contemplar as seguintes necessidades:

• Executar os testes o mais rápido possível
• Manter a estrutura de testes que o mantenedor do projeto (@dbmrq) está familiarizado
• Facilitar a compreensão dos testes para quem não conhece o projeto
• Em casos de erros, mostrar exatamente o que está errado
• Seja fácil copiar e colar os exemplos

Para fazer isso eu proponho:

• criar um suite de testes com base no cucumber / aruba, conforme explicado acima
• criar stages simultâneos para execução dos testes em paralelo -- o travis executa os seus testes (test.sh e os do cucumber) em duas máquinas virtuais em paralelo, não haverá diferença de tempo na execução dos seus testes atuais.
• se necessário, utilizar caches para agilizar o tempo de build (instalação do texlive por exemplo)
• publicar as especificações no relish, para tornar fácil compreensão e copia de exemplos -- como no projeto pandoc_abnt
• atualizar a máquina virtual do travis para o bionic (ubuntu-18.04)

[dbmrq]

@edusantana Maravilha! Desde que você esteja disposto a me ajudar quando eu tiver duvidas sobre o esquema novo, pode mandar ver! Inclusive, uma das maiores prioridades no momento é ver exatamente o que mudou com a norma de 2018 e atualizar os testes pra contemplá-la; já podemos aproveitar e ir vendo isso.

[edusantana]

@dbmrq com certeza estarei disposto a lhe ajudar.

Eu vou revisar o que já tinha feito (nem lembro mais), e vou continuar trabalhando na branch test, pessoalmente não gosto de gerenciar várias branches, mas no momento está bem. Assim que tiver boa eu faço o merge pra master e a gente apaga ela.

[edusantana]

Esses são os passos do BDD, inclusive na ordem de relevância.

[dbmrq]

Tá ótimo, obrigado! :D

[stale[bot]]

Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.