save cli
v0.3.10
O SAVE é uma estrutura de teste da linha de comando para todos os fins que pode ser usada para ferramentas de teste que funcionam com código, como analisadores e compiladores estáticos. É um aplicativo totalmente nativo, não exigindo necessidade de instalar nenhum SDK.
Análise estática A verificação e avaliação (SAVE) é um ecossistema (consulte também o salvamento) projetado para avaliação, teste e certificação de analisadores estáticos, compiladores ou quaisquer outras ferramentas de software. Em vez de desenvolver sua própria estrutura de teste, você pode utilizar o SAVE como um aplicativo de teste de linha de comando. O único requisito é preparar recursos de teste no formato apropriado.
Precisamos da sua ajuda! Ficaremos felizes se você usar, testar ou contribuir para este projeto. Caso você não tenha muito tempo para isso - pelo menos nos dê uma estrela para atrair outros colaboradores! Obrigado! ?
- Minha ferramenta de análise de código processa arquivos sequencialmente, um por um ;
- Produz avisos e os produz para Stdout ;
- Quero comparar avisos reais com avisos esperados que são especificados no código do recurso de teste .
- Eu também tenho ferramenta de análise de código, mas ela processa o projeto inteiro de uma só vez e está ciente de todas as relações de código.;
- Produz avisos e os produz para Stdout ;
- Quero comparar avisos reais com avisos esperados que são especificados no código do recurso de teste .
- Minha ferramenta manipula o código original, por exemplo, fixando-o automaticamente;
- Gostaria de verificar como minha ferramenta corrige o código comparando -o com o resultado esperado;
- Além disso, pode ser usado pelos compiladores para validar a geração de código , fazendo a transição da fonte original
- Código para representação intermediária (IR), outra linguagem de programação ou até montagem.
- Não quero especificar meus avisos esperados no código;
- Prefiro usar um arquivo separado no SARIF ou em qualquer outro formato.
save "/my/path/to/tests" Verifique se o diretório tests contém o arquivo de configuração save.toml .
Para depurar a execução do SAVE, você pode usar o seguinte argumento: --log=TYPE , onde TYPE pode ser um dos seguintes:
all - registro abrangente que inclui todas as informações da Salve Execution, ainda mais detalhadas que a depuração (semelhante a um rastreamento).debug - exibe resultados, avisos e informações de depuração.warnings - mostra resultados e avisos críticos.results_only - Exibe apenas os resultados. 
Aqui está uma lista de plugins padrão:
Se você deseja que vários plugins operem em seu diretório usando os mesmos arquivos de teste (recursos), basta adicioná -los à configuração save.toml :
[general]
...
[fix]
...
[warn]
...
[other plugin]
...
Você pode ler mais sobre o warn plugin aqui
O SAVE possui uma interface de linha de comando que permite executar a estrutura e o executável. Sua tarefa principal é configurar a saída do seu analisador estático para que o SAVE possa verificar se o erro apropriado foi sinalizado na linha correta do código de teste.
Para garantir que o aviso seja preciso para salvar, seu analisador estático deve gerar o resultado para o stderr/stdout ou um arquivo de log designado (por exemplo, no formato SARIF).
Você pode configurar o comportamento geral do SAVE usando argumentos da linha de comando ou usando um arquivo de configuração chamado save.properties . Este arquivo deve estar localizado no mesmo diretório que a configuração do teste raiz, save.toml .
Para obter uma lista abrangente de opções que podem ser passadas para salvar através da linha de comando ou do arquivo save.properties , consulte a tabela de opções ou execute o comando save --help . Esteja ciente de que as opções com opções são sensíveis ao maiúsculas.
A estrutura de salvamento detectará automaticamente seus testes, executará seu analisador neles, calculará a taxa de aprovação e os resultados dos testes de retorno no formato esperado.
Para ativar o SAVE para detectar suas suítes de teste, você deve colocar um arquivo save.toml em cada diretório contendo suítes de teste . É importante observar que esses arquivos de configuração herdam configurações dos diretórios dos pais.
Embora a maioria dos campos possa ser deixada indefinida em níveis mais baixos e possa herdar valores dos níveis superiores, você deve ser cauteloso. Alguns campos na seção [general] são obrigatórios para a execução; portanto, você precisa especificá -los em pelo menos um arquivo de configuração na cadeia de herança para testes que devem ser executados. Verifique quais campos são obrigatórios.
Por exemplo, com a seguinte hierarquia de diretório:
| A
| save.toml
| B
| save.toml
O save.toml no diretório B herdará as configurações e propriedades do diretório A.
Lembre -se de que o SAVE detectará todos os arquivos com o Postfix 'Teste' e utilizará automaticamente as configurações do arquivo save.toml presente no mesmo diretório (ou herdado do pai). Os testes são nomeados de acordo com o nome do recurso do arquivo de teste, excluindo o sufixo 'teste'. Se o Save detectar um arquivo com o Postfix 'Teste' nos recursos de teste e não conseguir localizar nenhuma configuração save.toml na hierarquia do diretório , ele apresentará um erro.
Por exemplo, o cenário abaixo é inválido e desencadeará um erro, pois a estrutura de salvamento não pode localizar o arquivo de configuração save.toml :
| A
| B
| myTest.java
Como mencionado anteriormente, o save.toml é essencial para a configuração de testes. Idealmente , deve haver um arquivo de configuração para cada diretório contendo testes, estabelecendo um relacionamento de um para muitos. Nós nos referimos a esses diretórios como test suites .
A lógica por trás de ter um único arquivo de configuração para um conjunto de testes é evitar configurações redundantes no mesmo conjunto de testes.
A configuração SALVE usa o formato TOML alimentado pelo projeto KTOML. Como mencionado acima, save.toml pode ser herdado da hierarquia do diretório (diretórios do pai).
O arquivo de configuração contém uma tabela [general] e uma tabela [plugins] . Para obter mais informações sobre plugins, consulte a seção Plugins.
Nesta seção, forneceremos informações apenas sobre a tabela [general] , que pode ser usada em todos os plugins.
[general]
# Your custom tags that will be used to detect groups of tests (required)
tags = ["parsing", "null-pointer", "etc"]
# Custom free text that describes the test suite (required)
description = "My suite description"
# Simple suite name (required)
suiteName = "DocsCheck", "CaseCheck", "NpeTests", "etc"
# Execution command (required at least once in the configuration hierarchy)
# By the default these binaries should be in the same directory of where SAVE is run
# or should have full or relational path (root - is the directory with save executable)
execCmd="./ktlint -R diktat-0.4.2.jar"
# Excluded tests in the suite (optional). Here, you can list the names of excluded tests, separated by commas. By default, no tests are excluded.
# To exclude tests, use the relative path to the root of the test project (to the root directory of `save.toml`)
excludedTests = ["warn/chapter1/GarbageTest.kt", "warn/otherDir/NewTest.kt", "etc"]
# Command execution time for one test (in milliseconds)
timeOutMillis = 10000
# Language for tests
language = "Kotlin"
Às vezes, você pode querer executar apenas um conjunto específico de testes em vez de executar todos os testes em uma configuração específica save.toml . Para conseguir isso, passe o caminho relativo ao arquivo de teste após todas as opções de configuração (root - é diretório com salvar binário):
$ save [options] /path/to/tests/Test1Você também pode fornecer uma lista de caminhos relativos aos arquivos de teste (separados por espaços):
$ save [options] /path/to/tests/Test1 /path/to/tests/Test2 O SALVE detectará automaticamente o arquivo save.toml mais próximo e usará a configuração dele.
Note: No Windows, lembre -se de usar uma barragem dupla \ como o separador do caminho.
O SAVE suporta vários formatos para saída do relatório de teste:
PLAIN : Uma tabela semelhante a um marel mostrando todos os resultados dos testes.PLAIN_FAILED : semelhante à PLAIN , mas exibe apenas testes com falha.JSON : Representação estruturada do resultado da execução. O formato desejado pode ser selecionado usando a opção --report-type=PLAIN .
O uso de analisadores estáticos é parte integrante do processo de desenvolvimento para todos os produtos de software. Embora os desenvolvedores de software possam escrever vários testes e obter uma boa cobertura de teste, o erro humano permanece inevitável. Tais erros podem resultar em perdas financeiras significativas para as empresas. A análise estática do programa ajuda a identificar e retificar bugs e questões que podem não ser detectáveis apenas através das validações do compilador.
A análise estática vem de várias formas e serve a propósitos diferentes. Pode envolver uma análise simples usando uma AST (abstrato de sintaxe árvore) ou aprofundar procedimentos mais complexos, como CFA (análise de fluxo de controle), análise interprocedural ou análise sensível ao contexto. Os analisadores estáticos podem avaliar o estilo de código, identificar possíveis problemas de tempo de execução na lógica do aplicativo, detectar cheiros de código e sugerir as melhores práticas. No entanto, permanece falta de clareza sobre as funções principais dos analisadores estáticos. Como sua eficácia pode ser quantificada? Quais critérios determinam sua aceitação? Quais funcionalidades são essenciais para os desenvolvedores que criam um novo analisador? Apesar dos anos de desenvolvimento estático do analisador, essas questões permanecem em grande parte sem resposta.
No início de sua jornada de desenvolvimento, todo criador de um analisador estático começa com a identificação dos tipos de problemas que sua ferramenta segmentará. Isso geralmente requer uma pesquisa por listas existentes de possíveis problemas ou pacotes de teste que podem orientar o processo de desenvolvimento, principalmente se seguir uma abordagem de TDD (desenvolvimento orientado a testes). Enquanto outros domínios da programação do sistema estabelecem referências e conjuntos de testes, como os benchmarks espec.org usados globalmente para avaliar vários componentes de software e hardware, não existem esses padrões para identificar problemas em linguagens de programação populares. Embora as diretrizes para codificação em C/C ++ tenham sido estabelecidas pela MISRA, não há equivalentes para idiomas amplamente utilizados como Python e Languages JVM. Existem suítes de teste disponíveis no NIST, mas sua estrutura e ecossistema são um pouco restritivos.
Dado esse cenário, os desenvolvedores costumam recriar mecanismos para análise estática ou desenvolver novas estruturas de teste, levando a um trabalho repetitivo. Alguns podem optar por diretrizes existentes, como o estilo de código do Google ou as regras do PMD, mas, independentemente da abordagem, o tempo significativo é invariavelmente gasto em conceituar, escrever e depurar testes.
O projeto usa o gradle como sistema de construção e pode ser construído usando o comando ./gradlew build .
Para compilar artefatos nativos, você deve instalar os pré -requisitos, conforme descrito na documentação Kotlin/Native.
Para acessar as dependências hospedadas no registro do pacote do Github, adicione o seguinte ao gradle.properties ou ~/.gradle/gradle.properties :
gprUser =<GH username>
gprKey =<GH personal access token> Um token de acesso pessoal pode ser gerado em https://github.com/settings/tokens/new. Verifique se o token possui um escopo que inclui read:packages .
Devido ao código gerado, você precisa executar a compilação uma vez para importar corretamente o projeto para um IDE com as importações resolvidas.
