save cli
v0.3.10
Saveは、静的アナライザーやコンパイラなどのコードを使用するツールのテストに使用できる、汎用コマンドラインテストフレームワークです。これは完全にネイティブアプリケーションであり、SDKをインストールする必要はありません。
静的分析の検証と評価（SAVE）は、静的アナライザー、コンパイラ、またはその他のソフトウェアツールの評価、テスト、および認証用に設計されたエコシステム（Save-Cloudも参照）です。独自のテストフレームワークを開発する代わりに、コマンドラインテストアプリケーションとしてSaveを利用できます。唯一の要件は、適切な形式でテストリソースを準備することです。
私たちはあなたの助けが必要です！このプロジェクトを使用、テスト、貢献していただければ幸いです。あなたがこれにあまり時間がない場合に備えて、少なくとも他の貢献者を引き付けるために私たちにスターを与えてください！ありがとう！ ？
- 私のコード分析ツールは、ファイルを1つずつ順番に処理します。
- 警告を生成し、それらを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には、フレームワークと実行可能ファイルの両方を実行できるコマンドラインインターフェイスがあります。主なタスクは、Saveが適切なエラーがテストコードの正しい行でフラグが付けられているかどうかを確認できるように、静的アナライザーの出力を構成することです。
保存のために警告が正確であることを確認するには、静的アナライザーが結果をSTDER/STDOUTまたは指定されたログファイル（SARIF形式など）に出力する必要があります。
コマンドライン引数を使用して、またはsave.propertiesという名前の構成ファイルを使用して、Saveの一般的な動作を構成できます。このファイルは、ルートテスト構成と同じディレクトリ、 save.tomlに配置する必要があります。
コマンドラインまたはsave.propertiesファイルを介して保存するために渡すことができるオプションの包括的なリストについては、オプションテーブルを参照するか、 save --helpコマンドを実行します。選択肢のあるオプションはケースに敏感であることに注意してください。
Save Frameworkは、テストを自動的に検出し、アナライザーを実行し、合格率を計算し、予想される形式でテスト結果を返すことができます。
SAVEを有効にするには、テストスイートを検出するには、各ディレクトリにテストスイートを含むsave.tomlファイルを配置する必要があります。これらの構成ファイルは、親ディレクトリから構成を継承していることに注意することが重要です。
ほとんどのフィールドは、より低いレベルで未定義のままにすることができ、上位レベルから値を継承することができますが、注意する必要があります。 [general]セクションの一部のフィールドは実行に必須であるため、実行することを目的としたテストのために、継承チェーンの少なくとも1つの構成ファイルでそれらを指定する必要があります。どのフィールドが必須であるかを確認してください。
たとえば、次のディレクトリ階層があります。
| A
| save.toml
| B
| save.toml
ディレクトリBのsave.tomlは、ディレクトリAから設定とプロパティを継承します。
Saveは、「テスト」Postfixを使用してすべてのファイルを検出し、同じディレクトリ（または親から継承されている）にあるsave.tomlファイルからの構成を自動的に使用することに留意してください。テストは、「テスト」の接尾辞を除くテストファイルのリソース名に従って命名されます。 Saveがテストリソースの「テスト」Postfixを使用してファイルを検出し、ディレクトリ階層にsave.toml構成を見つけることができない場合、エラーが発生します。
たとえば、以下のシナリオは無効であり、保存フレームワークではsave.toml構成ファイルを見つけることができないため、エラーがトリガーされます。
| A
| B
| myTest.java
前述のように、 save.tomlテストの構成に不可欠です。理想的には、テストを含む各ディレクトリに1つの構成ファイルがある必要があり、1対多くの関係を確立する必要があります。これらのディレクトリをtest suitesと呼びます。
1つのテストスイートに単一の構成ファイルを持つことの背後にある根拠は、同じテストスイート内の冗長構成を避けることです。
保存構成は、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 configですべてのテストを実行する代わりに、特定のテストセットのみを実行することをお勧めします。これを達成するには、すべての構成オプション（ルート - バイナリを保存したディレクトリ）の後にテストファイルへの相対パスを渡します。
$ save [options] /path/to/tests/Test1また、ファイルをテストする相対パスのリストを提供することもできます（スペースで区切られています）。
$ save [options] /path/to/tests/Test1 /path/to/tests/Test2保存は、最も近いsave.tomlファイルを自動的に検出し、そこから構成を使用します。
Note: Windowsでは、ダブルバックスラッシュ\パスセパレーターとして使用することを忘れないでください。
保存テストレポート出力のためのいくつかの形式をサポートします：
PLAIN ：すべてのテスト結果を示すマークダウンのようなテーブル。PLAIN_FAILED ： PLAINに似ていますが、表示されたテストのみが表示されます。JSON ：実行結果の構造化された表現。目的の形式は--report-type=PLAINオプションを使用して選択できます。
静的アナライザーの使用は、すべてのソフトウェア製品の開発プロセスの不可欠な部分です。ソフトウェア開発者はさまざまなテストを作成し、優れたテストカバレッジを達成する場合がありますが、ヒューマンエラーは避けられないままです。このようなエラーは、企業にとって大きな経済的損失をもたらす可能性があります。静的プログラム分析は、コンパイラの検証だけで検出できない可能性のあるバグと問題を特定して修正するのに役立ちます。
静的分析にはさまざまな形があり、さまざまな目的に役立ちます。 AST（抽象構文ツリー）を使用した簡単な分析を含むか、CFA（コントロールフロー分析）、操作間分析、またはコンテキストに敏感な分析などのより複雑な手順を掘り下げることが含まれます。静的アナライザーは、コードスタイルを評価し、アプリケーションロジックの潜在的なランタイムの問題を特定し、コードの匂いを検出し、ベストプラクティスを提案できます。ただし、静的アナライザーのコア関数について明確になっていない。それらの有効性はどのように定量化できますか？彼らの受け入れを決定する基準は何ですか？新しいアナライザーを作成する開発者にとって、どのような機能が不可欠ですか？長年の静的アナライザー開発にもかかわらず、これらの質問はほとんど答えられていません。
開発の旅の開始時に、静的アナライザーのすべての作成者は、ツールがターゲットにする問題の種類を特定することから始まります。これには、特にTDD（テスト駆動型開発）アプローチに従う場合、開発プロセスをガイドできる潜在的な問題またはテストパッケージの既存のリストを検索する必要があります。システムプログラミングの他のドメインは、さまざまなソフトウェアおよびハードウェアコンポーネントを評価するためにグローバルに使用されるSpec.orgベンチマークなど、ベンチマークとテストセットを確立していますが、一般的なプログラミング言語の問題を特定するための標準は存在しません。 C/C ++でのコーディングのガイドラインはMISRAによって確立されていますが、PythonやJVM言語などの広く使用されている言語に相当するものはありません。 NISTで利用可能なテストスイートがありますが、それらのフレームワークとエコシステムはやや制限的です。
このシナリオを考えると、開発者はしばしば、静的分析や新しいテストフレームワークを開発するためのメカニズムを再現し、繰り返し作業につながります。 GoogleコードスタイルやPMDルールなどの既存のガイドラインを選択する人もいますが、アプローチに関係なく、テストの概念化、書き込み、デバッグに常にかなりの時間が費やされます。
このプロジェクトは、Gradleをビルドシステムとして使用し、Command ./gradlew buildを使用して構築できます。
ネイティブアーティファクトをコンパイルするには、コトリン/ネイティブドキュメントに記載されているように、前提条件をインストールする必要があります。
GitHubパッケージレジストリにホストされている依存関係にアクセスするには、 gradle.propertiesまたは~/.gradle/gradle.propertiesのいずれかに以下を追加します。
gprUser =<GH username>
gprKey =<GH personal access token>個人的なアクセストークンは、https：//github.com/settings/tokens/newで生成できます。トークンにread:packages 。
生成されたコードのため、解決されたインポートでプロジェクトをIDEに正しくインポートするために、ビルドを1回実行する必要があります。
