Closed JaTvoiRabotnik closed 7 years ago
Sugestão: aguardemos os endpooints, então usamos "teste padrão" na base do assert de cada endpoint com material já homologado... Assim que detalharmos os endpoints posso detalhar como seriam os asserts e o controle (em base de dados) do material já homologado. Antes de gerar uma nova release, rodamos centenas ou milhares de asserts no localhost do server... Pensando na biblioteca de regular expressions prevista aqui no QueriDO, é uma das melhores garantias contra regressão.
Sim, concordo que precisamos de testes de funcionalidade e/ou testes de interface. Mas eu estou falando mais embaixo, de unit tests mesmo.
Ok, estamos em divida conosco para esboçar a arquitetura geral do sistema...Tentando expor a minha visão geral... teremos dois pacotes bem independentes:
o de pacote preservação e gestão das colaborações via base de dados e destinação final no git
, aquela coisa que estamos fazendo com as pastas html_original
, html_filtrado
e html_marcado
, mas idealmente só teria o html_original (e etc_original
para imgs e PDFs conforme decisão #16) no git (filesystem), o resto seria mantido e servido em base de dados.
e o pacote de transcrição (ou diversos pacotinhos especializados, ex. em Rio de Janeiro, em São Paulo, em Lei, em contrato, etc.).
Neles entram o reconhecimento automático de template (identificar se é texto de Lei ou texto de Portaria por exemplo) e as regular expressions de anotação, aquelas do nosso objetivo maior de destacar CNPJ, CEP, CPF, RG, etc. etc.
Os algoritmos pegam de uma etapa (ex. original) e devolvem a etapa seguinte para homologação...
Repare que neste cenário, o "teste" mais importante seria a homologação das etapas de transcrição: a primeira vez o ser humano homologa, em seguida, a cada modificação do software rodamos tudo denovo para ver se tudo o que foi antes homologado continua funcionando (asserts).
Copiado para a wiki
Vou ter que adiar esse issue ate uma estruturacao melhor da arquitetura mesmo. Por enquanto os testes que temos com o collect_htmls.py ja e suficiente, pra um teste manual.
O codigo esta ficando deveras complexo agora... Necessario criar testes pra garantir que nao esta havendo regressao de funcionalidade. Criar testes para getMateria e getHtm, cobrindo toda a funcionalidade existente no momento.