Propor um novo modelo de avaliação de QA.

[diraol]

Precisamos definir um modelo melhor de avaliação de qualidade de código (cobertura de testes, linters, etc).

Deixo à cargo da equipe da UNB 2017.01 fazer uma proposta! =)

[leonardofl]

+1

[leonardofl]

Oi Di... vi que vc adicionou o Codacy lá na home do nosso github. Legal, valeu! Aí esse Codacy é tipo uma alternativa ao code climate? Fiquei curioso que no code climate temos uma nota ruim, mas o codacy deu uma nota boa, hehe. Sabe explicar? Mas fora isso, acho q a ideia seria ficar com só um deles, neh? Também vi que parece q dá pra configurar a medição de cobertura de testes no codacy. Seria legal. Na época tentei fazer isso pro code climate, mas tive problemas, e acabei deixando só a medição de cobertura da app modelagem. Valeu Di!

…

On 22 March 2017 at 08:44, Diego Rabatone Oliveira ***@***.*** > wrote: Precisamos definir um modelo melhor de avaliação de qualidade de código (cobertura de testes, linters, etc). Deixo à cargo da equipe da UNB 2017.01 fazer uma proposta! =) — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#420>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAWJPXSF-uEDYTEUwKDjvKIlCR6Vc9hOks5roQmLgaJpZM4MlE4v> .

[diraol]

Oi Léo!
Adicionei de forma experimental mesmo, para testarmos e ver como cada um funciona e o que se adapta melhor às nossas necessidades (?! rs)

Sobre a diferença entre eles, ainda não consegui ver. se o pessoal da UNB puder ajudar será uma ajuda super bem vinda! ;)

Outra coisa, fiz algumas alterações no setup da nossa conta do github de forma que agora PR só pode ser aceita se passar por review de alguém e se estiver passando nos testes (inclusive no code climate).

[leonardofl]

PR só pode ser aceita se passar por review

humm... ainda não saquei tão bem esse review, mas acho q no próximo PR eu capto melhor.

e se estiver passando nos testes (inclusive no code climate).

hum, não tendi muito... pq o code climate não tá vendo legal os testes... tá vendo só uma app... pra checar o status da build seria melhor pegar do travis...

[diraol]

pessoal do time @radar-parlamentar/unb-mes-2017-1 , num outro projeto em que estou trabalhando estamos testando neste instante migrar do travis + codeclimate para o scrutinizer. Aparentemente ele consegue fazer os testes (papel atual do travis) e também a parte de code-quality (codacy, codeclimeate, coverage/coveralls, etc). Acho que pode ser uma boa solução em termos de reduzir o número de ferramentas utilizadas e setups a serem feitos, integrando tudo num lugar só!

Se quiserem dar uma olhada no setup que temos neste outro projeto, vocês pode ver aqui:

• https://github.com/kytos/python-openflow

Se não me engano os arquivos mais importantes a serem olhados são:

• .scrutinizer.yml
• .coveragerc
• setup.cfg
• setup.py
• docs/Makefile[1]

[1] esse é para doctest do projeto, não temos isso muito bem alinhado até agora no Radar, mas acho que para um futuro passo do projeto pode ser muito legal, pode ajudar muito no entendimento do projeto gerando documentação automatizada (com Sphinx) a partir das documentações das próprias classes. Eu não colocaria isso nesse semestre, mas estou documentando aqui para manter o registro ;)

[suzukijessica]

Vamos olhar e definir melhor essa parte da qualidade. Obrigada

[diraol]

@cemsbr, rola você dar uma ajuda para nós automatizarmos teste de QA (pylama talvez?) aqui no Radar? =)

[cemsbr]

Tentei me atualizar em relação às ferramentas há não muito tempo atrás e talvez eu possa ser útil. Acho que vão gostar das várias alternativas que testei em um projeto meu. Ele está no começo, mas já dá uma boa ideia das ferramentas pelo readme e por um PR propositadamente ruim.

Particularmente, eu achei que o scrutinizer tem um conjunto de features maior. Porém, gostei dos comentários do coveralls no PR e, caso queira algo ainda mais detalhado sobre testes, veja o comentário do codecov. Eu ficaria com scrutinizer + coveralls, mas ninguém melhor para opinar do que os devs do radar!

[cemsbr]

Ah, sobre pylama, o mantenedor não é muito ativo e as ferramentas estão mudando rapidamente, mesmo o pycodestyle. Se eu tivesse que configurar um novo projeto, eu colocaria pelo menos pylint e depois complementaria com outras avaliações caso ele não tenha (não lembro de cabeça), como por exemplo pydocstyle (docstrings), radon (complexidade), isort (imports), etc.

[leonardofl]

Oi Cadu! Obrigado pelas dicas!!! Sei que no momento a prioridade é a migração pro Python 3, mas lembrando ao time que essas ferramentas trazem um grande benefício justamente em um cenário de refatoração intensa ;) []s!, Léo 2017-05-21 0:41 GMT-03:00 Carlos Eduardo Moreira dos Santos < [email protected]>:

…

Ah, sobre pylama, o mantenedor não é muito ativo e as ferramentas estão mudando rapidamente, mesmo o pydocstyle. Se eu tivesse que configurar um novo projeto, eu colocaria pelo menos pylint e depois complementaria com outras avaliações caso ele não tenha (não lembro de cabeça), como por exemplo pydocstyle (docstrings), radon (complexidade), isort (imports), etc. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#420 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAWJPUzd1ahudh2VZCsQouMT5pc1EQ35ks5r77JtgaJpZM4MlE4v> .

[cemsbr]

Depois de alguns problemas com o pylama, resolvi criar o yala que pode interessar a vocês.