save cli

保存是一個通用命令行測試框架，可用於測試與代碼合作的工具，例如靜態分析儀和編譯器。這是一個完全本地的應用程序，不需要安裝任何SDK。

什麼是保存？

靜態分析驗證和評估（保存）是一個生態系統（另請參見Save-Cloud），旨在評估，測試和認證靜態分析儀，編譯器或任何其他軟件工具。您可以利用另存為命令行測試應用程序，而不是開發自己的測試框架。唯一的要求是以適當的格式準備測試資源。

貢獻

我們需要您的幫助！如果您將使用，測試或為該項目做出貢獻，我們將很高興。如果您沒有太多時間來做到這一點 - 至少給我們一個明星吸引其他貢獻者！謝謝！ ？

快速開始：用戶方案

1。靜態分析，警告，順序

• 我的代碼分析工具依次依次處理文件；
• 它發出警告並將其輸出到stdout ；
• 我想將實際警告與測試資源代碼中指定的預期警告進行比較。

2。靜態分析，警告，處理整個項目

• 我也有代碼分析工具，但是它立即處理整個項目，並意識到所有代碼關係。
• 它發出警告並將其輸出到stdout ；
• 我想將實際警告與測試資源代碼中指定的預期警告進行比較。

3。自動代碼修復或發電

• 例如，我的工具通過自動固定來操縱原始代碼。
• 我想通過將代碼與預期結果進行比較來檢查我的工具如何修復代碼；
• 此外，編譯器可以使用它來驗證代碼生成，從原始源過渡
• 代碼中間表示（IR），另一種編程語言，甚至是組裝。

4。分離文件中的預期警告

• 我不想在代碼中指定我的預期警告；
• 我更喜歡使用SARIF或任何其他格式的單獨文件。

如何運行

1. 下載適合您的操作系統和體系結構的最新版本。
2. 設置並以正確的保存格式配置測試基礎。有關指導，請參閱test_detection和插件。
3. 執行以下命令（根據您的體系結構和操作系統對其進行修改）： save "/my/path/to/tests"

確保tests目錄包含save.toml配置文件。

保存記錄

要調試保存執行，您可以使用以下參數： --log=TYPE ，其中TYPE可以是以下內容之一：

• all - 全面的日誌記錄，其中包括保存執行的所有信息，甚至比調試（類似於跟踪）更詳細。
• debug - 顯示結果，警告和調試信息。
• warnings - 顯示結果和關鍵警告。
• results_only僅顯示結果。

帶有示例的插件

這是標準插件的列表：

• 警告插件：這是用於檢測源代碼中問題並發出警告的測試工具。
• 修復插件：這用於測試修改文本的靜態分析儀工具。
• FIX-and-WARN插件：對您要糾正文件並隨後檢查該工具無法在一次運行中無法解決的警告的方案的優化。

如果要使用相同的測試文件（資源）在目錄中運行多個插件，只需將它們全部添加到save.toml配置：

 [general]
...

[fix]
...

[warn]
...

[other plugin]
...

保存警告DSL

您可以在此處閱讀有關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 。

一個測試套件的單個配置文件背後的理由是避免在同一測試套件中冗餘配置。

Save.toml配置文件

保存配置使用由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。