save cli
v0.3.10
保存是一个通用命令行测试框架，可用于测试与代码合作的工具，例如静态分析仪和编译器。这是一个完全本地的应用程序，不需要安装任何SDK。
静态分析验证和评估（保存）是一个生态系统（另请参见Save-Cloud），旨在评估，测试和认证静态分析仪，编译器或任何其他软件工具。您可以利用另存为命令行测试应用程序，而不是开发自己的测试框架。唯一的要求是以适当的格式准备测试资源。
我们需要您的帮助！如果您将使用，测试或为该项目做出贡献，我们将很高兴。如果您没有太多时间来做到这一点 - 至少给我们一个明星吸引其他贡献者！谢谢！ ？
- 我的代码分析工具依次依次处理文件；
- 它发出警告并将其输出到stdout ；
- 我想将实际警告与测试资源代码中指定的预期警告进行比较。
- 我也有代码分析工具，但是它立即处理整个项目，并意识到所有代码关系。
- 它发出警告并将其输出到stdout ；
- 我想将实际警告与测试资源代码中指定的预期警告进行比较。
- 例如，我的工具通过自动固定来操纵原始代码。
- 我想通过将代码与预期结果进行比较来检查我的工具如何修复代码；
- 此外，编译器可以使用它来验证代码生成，从原始源过渡
- 代码中间表示（IR），另一种编程语言，甚至是组装。
- 我不想在代码中指定我的预期警告；
- 我更喜欢使用SARIF或任何其他格式的单独文件。
save "/my/path/to/tests"确保tests目录包含save.toml配置文件。
要调试保存执行，您可以使用以下参数： --log=TYPE ，其中TYPE可以是以下内容之一：
all - 全面的日志记录，其中包括保存执行的所有信息，甚至比调试（类似于跟踪）更详细。debug - 显示结果，警告和调试信息。warnings - 显示结果和关键警告。results_only仅显示结果。 
这是标准插件的列表：
如果要使用相同的测试文件（资源）在目录中运行多个插件，只需将它们全部添加到save.toml配置：
[general]
...
[fix]
...
[warn]
...
[other plugin]
...
您可以在此处阅读有关warn plugin的更多信息
Save具有一个命令行接口，可让您同时运行框架和可执行文件。您的主要任务是配置静态分析仪的输出，以便保存可以验证是否在测试代码的正确行中标记了适当的错误。
为了确保警告准确保存，您的静态分析仪必须将结果输出到stderr/stdout或指定的日志文件（例如，以SARIF格式）。
您可以使用命令行参数或使用名为save.properties的配置文件来配置Save的常规行为。该文件应与root Test Config， save.toml位于同一目录中。
有关可以通过命令行或save.properties文件保存的选项的全面列表，请参阅选项表或执行save --help命令。请注意，选择的选项对病例敏感。
保存框架将自动检测您的测试，对它们进行分析仪，计算通过率并以预期格式返回测试结果。
要启用保存以检测您的测试套件，您必须在包含测试套件的每个目录中放置一个save.toml文件。重要的是要注意，这些配置文件从父目录继承了配置。
尽管大多数字段可以在较低的级别上保持不确定，并且可以从顶级继承值，但您应该谨慎。 [general]部分中的某些字段是必须执行的，因此您需要在继承链中的至少一个配置文件中指定它们，以进行运行的测试。检查哪些字段是强制性的。
例如，具有以下目录层次结构：
| A
| save.toml
| B
| save.toml
目录B中的save.toml将继承目录A的设置和属性。
请记住，保存将使用“测试”后缀检测所有文件，并将自动从同一目录中（或从父母继承）中的save.toml文件中自动使用配置。测试根据测试文件的资源名称命名，不包括“测试”后缀。如果保存在测试资源中的“测试”后缀中检测到文件，并且无法找到任何save.toml配置在目录层次结构中，则会丢弃错误。
例如，下面的方案无效，并且会触发错误，因为保存框架无法找到save.toml配置文件：
| A
| B
| myTest.java
如前所述， save.toml对于配置测试至关重要。理想情况下，每个包含测试的目录应该有一个配置文件，建立一对一的关系。我们将这些目录称为test suites 。
一个测试套件的单个配置文件背后的理由是避免在同一测试套件中冗余配置。
保存配置使用由KTOML项目供电的TOML格式。如上所述， save.toml可以从目录层次结构（父目录）继承。
配置文件包含一个[general]表和[plugins]表。有关插件的更多信息，请参阅“插件”部分。
在本节中，我们将仅提供有关[general]表的信息，该表可在所有插件中使用。
[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"
有时，您可能只想执行一组特定的测试，而不是在特定的save.toml配置下运行所有测试。为此，请在所有配置选项（root-是带有保存二进制的目录）之后，将相对路径传递到测试文件：
$ save [options] /path/to/tests/Test1您还可以提供测试文件的相对路径列表（由空格分开）：
$ save [options] /path/to/tests/Test1 /path/to/tests/Test2保存将自动检测最近的save.toml文件并使用其配置。
Note:在Windows上，请记住使用双重斜线\作为路径分离器。
SAVE支持几种格式用于测试报告输出：
PLAIN ：类似降价的表，显示了所有测试结果。PLAIN_FAILED ：类似于PLAIN ，但仅显示失败的测试。JSON ：执行结果的结构化表示。可以使用--report-type=PLAIN选项选择所需的格式。
使用静态分析仪是每个软件产品开发过程不可或缺的一部分。尽管软件开发人员可能会编写各种测试并获得良好的测试范围，但人为错误仍然不可避免。这样的错误可能会给公司带来巨大的财务损失。静态程序分析有助于识别和纠正仅通过编译器验证而无法检测到的错误和问题。
静态分析有各种形式，并且有不同的目的。它可能涉及使用AST（抽象语法树）的简单分析，也可能涉及更复杂的过程，例如CFA（控制流分析），概要分析或上下文敏感分析。静态分析仪可以评估代码样式，在应用程序逻辑中查明潜在的运行时问题，检测代码气味并提出最佳实践。但是，对于静态分析仪的核心功能仍然缺乏清晰度。如何量化其功效？哪些标准决定了他们的接受？哪些功能对于创建新分析仪的开发人员至关重要？尽管经过多年的静态分析仪的开发，这些问题仍未得到答案。
在开发过程中，静态分析仪的每个创建者都始于确定其工具将针对的问题。这通常需要搜索可以指导开发过程的潜在问题或测试包的现有列表，尤其是在遵循TDD（测试驱动开发）方法的情况下。尽管系统编程中的其他域已经建立了基准和测试集，例如全球用于评估各种软件和硬件组件的Spec.org基准，但尚无此类标准来识别流行的编程语言中的问题。尽管Misra已经制定了C/C ++编码的指南，但对于Python和JVM语言等广泛使用的语言，没有等效物。 NIST有测试套件，但是它们的框架和生态系统有些限制。
鉴于这种情况，开发人员经常发现自己重新创建静态分析或开发新的测试框架的机制，从而导致重复性工作。有些人可能会选择诸如Google Code样式或PMD规则之类的现有准则，但是无论采用哪种方法，大量时间总是花在概念化，写作和调试测试上。
该项目使用Gradle作为其构建系统，可以使用命令./gradlew build 。
要编译本地工件，您必须按照Kotlin/本机文档中所述安装先决条件。
要访问GitHub软件包注册表上托管的依赖项，请将以下内容添加到gradle.properties或~/.gradle/gradle.properties ：
gprUser =<GH username>
gprKey =<GH personal access token>可以在https://github.com/settings/tokens/new上生成个人访问令牌。确保令牌具有包含read:packages 。
由于生成的代码，您需要运行一次构建，以将项目正确导入具有解决导入的IDE。
