save cli
v0.3.10
Save ist ein Allzweck-Befehlszeilen-Test-Framework, das zum Testen von Tools verwendet werden kann, die mit Code funktionieren, z. B. statische Analysatoren und Compiler. Es handelt sich um eine vollständig native Anwendung, die keine SDK installieren muss.
Die statische Analyseverifizierung und -bewertung (SAVE) ist ein Ökosystem (auch siehe Save-Cloud), das für die Bewertung, Test und Zertifizierung statischer Analysatoren, Compiler oder anderer Softwaretools entwickelt wurde. Anstatt Ihr eigenes Test-Framework zu entwickeln, können Sie Save als Befehlszeilen-Testanwendung verwenden. Die einzige Anforderung besteht darin, Testressourcen im entsprechenden Format vorzubereiten.
Wir brauchen Ihre Hilfe! Wir werden uns freuen, wenn Sie dieses Projekt verwenden, testen oder beitragen. Für den Fall, dass Sie nicht viel Zeit dafür haben - geben Sie uns zumindest einen Star , um andere Mitwirkende anzulocken! Danke! ?
- Mein Code -Analyse -Tool verarbeitet Dateien nacheinander nacheinander.
- Es erzeugt Warnungen und gibt sie an stdout aus;
- Ich möchte die tatsächlichen Warnungen mit den erwarteten Warnungen vergleichen, die im Testressourcencode angegeben sind.
- Ich habe auch Codeanalyse -Tool, es verarbeitet das gesamte Projekt gleichzeitig und ist sich aller Codebeziehungen bewusst.
- Es erzeugt Warnungen und gibt sie an stdout aus;
- Ich möchte die tatsächlichen Warnungen mit den erwarteten Warnungen vergleichen, die im Testressourcencode angegeben sind.
- Mein Werkzeug manipuliert den Originalcode beispielsweise, indem er ihn automatisch fixiert.
- Ich möchte überprüfen, wie mein Tool den Code behebt, indem ich ihn mit dem erwarteten Ergebnis vergleicht.
- Darüber hinaus kann es von Compilern verwendet werden, um die Codeerzeugung zu validieren und aus der ursprünglichen Quelle zu wechseln
- Code zur Zwischendarstellung (IR), eine andere Programmiersprache oder sogar Assembly.
- Ich möchte meine erwarteten Warnungen im Code nicht angeben.
- Ich bevorzuge es, eine separate Datei in Sarif oder einem anderen Format zu verwenden.
save "/my/path/to/tests" Stellen Sie sicher, dass das tests die Konfigurationsdatei save.toml enthält.
Um die Speicherung der Ausführung zu debuggen, können Sie das folgende Argument verwenden: --log=TYPE , wobei TYPE einer der folgenden sein kann:
all - umfassende Protokollierung, die alle Informationen aus der Save Execution enthält, noch detaillierter als Debug (ähnlich wie eine Spur).debug - Zeigt Ergebnisse, Warnungen und Debug -Informationen an.warnings - zeigt Ergebnisse und kritische Warnungen.results_only - Zeigt nur die Ergebnisse an. 
Hier ist eine Liste von Standard -Plugins:
Wenn Sie möchten, dass mehrere Plugins mit denselben Testdateien (Ressourcen) in Ihrem Verzeichnis arbeiten, fügen Sie sie einfach alle zur save.toml -Konfiguration hinzu:
[general]
...
[fix]
...
[warn]
...
[other plugin]
...
Weitere Informationen zum warn plugin finden Sie hier
Save verfügt über eine Befehlszeilenschnittstelle, mit der Sie sowohl das Framework als auch Ihre ausführbare Datei ausführen können. Ihre Hauptaufgabe besteht darin, die Ausgabe Ihres statischen Analysators so zu konfigurieren, dass das Speichern überprüfen kann, ob der entsprechende Fehler in der richtigen Zeile des Testcodes gekennzeichnet wurde.
Um sicherzustellen, dass die Warnung für das Speichern korrekt ist, muss Ihr statischer Analysator das Ergebnis entweder an stderr/stdout oder eine bestimmte Protokolldatei ausgeben (z. B. im SARIF -Format).
Sie können das allgemeine Verhalten von Save mithilfe von Befehlszeilenargumenten oder mithilfe einer Konfigurationsdatei namens save.properties konfigurieren. Diese Datei sollte sich im selben Verzeichnis wie die Root -Testkonfiguration save.toml befinden.
Für eine umfassende Liste der Optionen, die über die Befehlszeile oder die Datei save.properties zum Speichern übergeben werden können, finden Sie in der Tabelle Optionen oder führen Sie den Befehl save --help aus. Bitte beachten Sie, dass Optionen mit Auswahlmöglichkeiten von Fall sensitiv sind.
Das Save -Framework erkennt Ihre Tests automatisch, führt Ihren Analysator auf sie aus, berechnet die Passquote und die Rückgabe -Testergebnisse im erwarteten Format.
Um das Speichern zu aktivieren, um Ihre Testsuiten zu erkennen, müssen Sie in jedem Verzeichnis, das Testsuiten enthält, eine save.toml -Datei einsetzen. Es ist wichtig zu beachten, dass diese Konfigurationsdateien Konfigurationen aus übergeordneten Verzeichnissen erben.
Obwohl die meisten Felder auf niedrigeren Ebenen undefiniert bleiben und Werte von den oberen Ebenen erben können, sollten Sie vorsichtig sein. Einige Felder im Abschnitt [general] sind für die Ausführung obligatorisch. Sie müssen daher in mindestens einer Konfigurationsdatei in der Erbschaftskette für Tests angeben, die ausgeführt werden sollen. Überprüfen Sie, welche Felder obligatorisch sind.
Zum Beispiel mit der folgenden Verzeichnishierarchie:
| A
| save.toml
| B
| save.toml
Die save.toml in Verzeichnis B erben Einstellungen und Eigenschaften aus dem Verzeichnis A.
Denken Sie daran, dass Speichern alle Dateien mit dem Postfix "Test" erkennt und automatisch Konfigurationen aus der in demselben Verzeichnis vorhandenen save.toml -Datei verwendet oder von übergeordneten geerbt). Tests werden gemäß dem Ressourcennamen der Testdatei ohne das "Test" -Suffix benannt. Wenn speichern eine Datei mit dem "Test" -Postfix in den Testressourcen erfasst und keine save.toml .
Beispielsweise ist das folgende Szenario ungültig und löst einen Fehler aus, da das Speichern -Framework die save.toml speichern kann.
| A
| B
| myTest.java
Wie bereits erwähnt, ist das save.toml für die Konfiguration von Tests unerlässlich. Im Idealfall sollte es für jedes Verzeichnis eine Konfigurationsdatei geben, die Tests enthält, die eine Eins-zu-Viele-Beziehung aufbauen. Wir bezeichnen diese Verzeichnisse als test suites .
Die Begründung hinter einer einzelnen Konfigurationsdatei für eine Testsuite besteht darin, redundante Konfigurationen innerhalb derselben Testsuite zu vermeiden.
Die Konfiguration speichern verwendet das vom KTOML -Projekt betriebene TOML -Format. Wie oben erwähnt, kann save.toml aus der Verzeichnishierarchie (übergeordnete Verzeichnisse) vererbt werden.
Die Konfigurationsdatei enthält eine [general] Tabelle und eine [plugins] -Tabelle. Weitere Informationen zu Plugins finden Sie im Abschnitt Plugins.
In diesem Abschnitt geben wir nur Informationen über die [general] Tabelle an, die für alle Plugins verwendet werden kann.
[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"
Manchmal möchten Sie möglicherweise nur eine bestimmte Reihe von Tests ausführen, anstatt alle Tests unter einer bestimmten save.toml auszuführen. Um dies zu erreichen, übergeben Sie den relativen Pfad nach allen Konfigurationsoptionen (Root - ist ein Verzeichnis mit Save Binary):
$ save [options] /path/to/tests/Test1Sie können auch eine Liste relativer Pfade zum Testen von Dateien (durch Leerzeichen getrennt) angeben:
$ save [options] /path/to/tests/Test1 /path/to/tests/Test2 Speichern wird automatisch die nächstgelegene Datei save.toml erkennen und die Konfiguration davon verwenden.
Note: Denken Sie unter Windows daran, einen doppelten Backslash \ als Pfadabscheider zu verwenden.
Speichern unterstützt verschiedene Formate für die Ausgabe von Testberichten:
PLAIN : Eine markdownartige Tabelle, die alle Testergebnisse zeigt.PLAIN_FAILED : Ähnlich wie PLAIN , aber nur fehlgeschlagene Tests.JSON : Strukturierte Darstellung des Ausführungsergebnisses. Das gewünschte Format kann mit der Option --report-type=PLAIN ausgewählt werden.
Die Verwendung statischer Analysatoren ist ein wesentlicher Bestandteil des Entwicklungsprozesses für jedes Softwareprodukt. Während Softwareentwickler verschiedene Tests schreiben und eine gute Testabdeckung erreichen können, bleibt das menschliche Fehler unvermeidlich. Solche Fehler können zu erheblichen finanziellen Verlusten für Unternehmen führen. Die statische Programmanalyse hilft bei der Identifizierung und Behebung von Fehler und Problemen, die möglicherweise nicht allein durch Compiler -Validierungen erkennbar sind.
Die statische Analyse erfolgt in verschiedenen Formen und dient unterschiedlichen Zwecken. Es kann eine einfache Analyse unter Verwendung eines AST-Syntaxbaums (abstrakter Syntaxbaum) oder in komplexere Verfahren wie CFA (Kontroll-Flow-Analyse), interprozeduraler Analyse oder kontextempfindlicher Analyse eingehen. Statische Analysatoren können den Codestil bewerten, potenzielle Laufzeitprobleme in Anwendungslogik bestimmen, Codegerüche erkennen und Best Practices vorschlagen. Es bleibt jedoch ein Mangel an Klarheit über die Kernfunktionen statischer Analysatoren. Wie kann ihre Wirksamkeit quantifiziert werden? Welche Kriterien bestimmen ihre Akzeptanz? Welche Funktionen sind für Entwickler, die einen neuen Analysator erstellen, von wesentlicher Bedeutung? Trotz jahrelanger Entwicklung der statischen Analyszer sind diese Fragen weitgehend unbeantwortet.
Zu Beginn seiner Entwicklungsreise beginnt jeder Schöpfer eines statischen Analysators mit der Ermittlung der Art von Problemen, die sein Tool abzielen wird. Dies erfordert häufig eine Suche nach vorhandenen Listen potenzieller Probleme oder Testpakete, die den Entwicklungsprozess leiten können, insbesondere wenn sie einem TDD-Ansatz (Test-gesteuerte Entwicklung) folgen. Während andere Domänen in der Systemprogrammierung Benchmarks und Testsätze festgelegt haben, wie z. Während Richtlinien für die Codierung in C/C ++ von Misra festgelegt wurden, gibt es keine Äquivalente für weit verbreitete Sprachen wie Python und JVM-Spragen. Bei NIST gibt es Testsuiten, aber ihr Rahmen und ihr Ökosystem sind etwas restriktiv.
Angesichts dieses Szenarios finden Entwickler häufig wiederholte Mechanismen für die statische Analyse oder die Entwicklung neuer Testrahmen, was zu wiederholten Arbeiten führt. Einige entscheiden sich möglicherweise für vorhandene Richtlinien wie den Google -Code -Stil oder die PMD -Regeln, aber unabhängig vom Ansatz wird eine erhebliche Zeit immer für die Konzeption, Schreiben und Debugging -Tests aufgewendet.
Das Projekt verwendet Gradle als Build -System und kann mit dem Befehl./Gradlew ./gradlew build erstellt werden.
Um native Artefakte zu erstellen, müssen Sie die Voraussetzungen wie in der Kotlin/Native -Dokumentation beschrieben installieren.
Um auf Abhängigkeiten zuzugreifen, die in der GitHub -Paketregistrierung gehostet werden, fügen Sie Folgendes entweder zu gradle.properties oder ~/.gradle/gradle.properties hinzu:
gprUser =<GH username>
gprKey =<GH personal access token> Ein persönlicher Zugriffs -Token kann unter https://github.com/setings/tokens/new generiert werden. Stellen Sie sicher, dass das Token über einen Umfang verfügt, der read:packages .
Aufgrund des generierten Code müssen Sie den Build einmal ausführen, um das Projekt mit behobenen Importen korrekt in eine IDE zu importieren.
