save cli
v0.3.10
Save는 정적 분석기 및 컴파일러와 같이 코드와 함께 작동하는 도구를 테스트하는 데 사용할 수있는 다목적 명령 줄 테스트 프레임 워크입니다. SDK를 설치할 필요가없는 완전 기본 응용 프로그램입니다.
정적 분석 검증 및 평가 (저장)는 정적 분석기, 컴파일러 또는 기타 소프트웨어 도구의 평가, 테스트 및 인증을 위해 설계된 생태계 (저장 클라우드 참조)입니다. 고유 한 테스트 프레임 워크를 개발하는 대신 저장을 명령 줄 테스트 응용 프로그램으로 활용할 수 있습니다. 유일한 요구 사항은 적절한 형식으로 테스트 리소스를 준비하는 것입니다.
우리는 당신의 도움이 필요합니다! 이 프로젝트를 사용, 테스트 또는 기여하면 기뻐할 것입니다. 당신이 이것에 대한 시간이 많지 않은 경우 - 적어도 우리에게 다른 기고자들을 끌어 들이기 위해 스타를주십시오 ! 감사해요! ?
- 내 코드 분석 도구는 파일을 하나씩 순차적으로 처리합니다.
- 그것은 경고를 만들어 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가 적절한 오류가 올바른 테스트 코드의 올바른 줄에 표시되었는지 여부를 확인할 수 있도록하는 것입니다.
저장을 위해 경고가 정확한지 확인하려면 정적 분석기는 결과를 STDERR/STDOUT 또는 지정된 로그 파일 (예 : SARIF 형식)으로 출력해야합니다.
명령 줄 인수를 사용하여 Save의 일반 동작을 구성하거나 save.properties 라는 구성 파일을 사용하여 구성 할 수 있습니다. 이 파일은 루트 테스트 구성, save.toml 과 동일한 디렉토리에 있어야합니다.
명령 줄 또는 save.properties 을 통해 저장하기 위해 전달할 수있는 포괄적 인 옵션 목록은 옵션 테이블을 참조하거나 save --help 명령을 실행하십시오. 선택한 옵션은 대소 문자에 민감합니다.
저장 프레임 워크는 테스트를 자동으로 감지 하고 분석기를 실행하며 패스 속도를 계산하며 예상 형식의 테스트 결과를 반환합니다.
저장을 할 수 있도록 테스트 스위트를 감지하려면 각 디렉토리 가 포함 된 각 디렉토리에 save.toml 파일을 배치해야합니다. 이러한 구성 파일은 부모 디렉토리에서 구성을 상속 받는다는 점에 유의해야합니다.
대부분의 필드는 낮은 레벨에서 정의되지 않고 최상위 레벨에서 값을 상속받을 수 있지만 조심해야합니다. [general] 섹션의 일부 필드는 실행에 필수적이므로 실행하려는 테스트를 위해 상속 체인의 하나 이상의 구성 파일로 지정해야합니다. 어떤 필드가 필수인지 확인하십시오.
예를 들어, 다음 디렉토리 계층 구조를 사용하면 다음과 같습니다.
| A
| save.toml
| B
| save.toml
디렉토리 B의 save.toml 은 디렉토리 A에서 설정 및 속성을 상속합니다.
Save는 'Test'PostFix로 모든 파일을 감지하고 save.toml 파일에서 동일한 디렉토리 (또는 부모로부터 상속)에서 구성을 자동으로 사용합니다. 테스트는 '테스트'접미어를 제외하고 테스트 파일의 리소스 이름에 따라 명명되었습니다. 저장은 테스트 리소스에서 '테스트'postfix로 파일을 감지하고 디렉토리 계층 구조 에서 save.toml 구성을 찾을 수없는 경우 오류가 발생합니다.
예를 들어, 아래 시나리오는 유효하지 않으며 저장 프레임 워크가 save.toml 구성 파일을 찾을 수 없으므로 오류가 발생합니다.
| A
| B
| myTest.java
앞에서 언급했듯이 save.toml 은 테스트를 구성하는 데 필수적입니다. 이상적으로는 테스트가 포함 된 각 디렉토리에 대해 하나의 구성 파일이 있어야하며 일대일 관계를 설정해야합니다. 우리는이 디렉토리를 test suites 라고합니다.
하나의 테스트 스위트에 대한 단일 구성 파일을 갖는 근거는 동일한 테스트 스위트 내에서 중복 구성을 피하는 것입니다.
Save Configuration은 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 구성에서 모든 테스트를 실행하는 대신 특정 테스트 세트 만 실행할 수 있습니다. 이를 달성하려면 모든 구성 옵션 (루트 - Save Binary가있는 디렉토리) 후에 상대 경로를 테스트 파일로 전달하십시오.
$ 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 (Abstract Syntax Tree)를 사용한 간단한 분석이 포함되거나 CFA (Control-Flow Analysis), 간질 분석 또는 상황에 민감한 분석과 같은보다 복잡한 절차를 탐구 할 수 있습니다. 정적 분석기는 코드 스타일을 평가하고 응용 프로그램 로직에서 잠재적 인 런타임 문제를 정확히 찾아서 코드 냄새를 감지하며 모범 사례를 제안 할 수 있습니다. 그러나 정적 분석기의 핵심 기능에 대한 명확성이 여전히 남아 있습니다. 그들의 효능은 어떻게 정량화 될 수 있습니까? 어떤 기준이 그들의 수용을 결정합니까? 새로운 분석기를 만드는 개발자에게는 어떤 기능이 필수적입니까? 수년간의 정적 분석기 개발에도 불구하고, 이러한 질문은 크게 답변되지 않습니다.
개발 여정이 시작될 때 정적 분석기의 모든 제작자는 도구가 목표로하는 문제의 종류를 식별하는 것으로 시작합니다. 이를 위해서는 종종 TDD (테스트 중심 개발) 접근법을 따르는 경우 개발 프로세스를 안내 할 수있는 기존 문제 또는 테스트 패키지 목록을 검색해야합니다. 시스템 프로그래밍의 다른 도메인은 다양한 소프트웨어 및 하드웨어 구성 요소를 평가하는 데 전 세계적으로 사용되는 Spec.org 벤치 마크와 같은 벤치 마크 및 테스트 세트를 설정했지만 인기있는 프로그래밍 언어의 문제를 식별하기위한 표준은 존재하지 않습니다. C/C ++의 코딩에 대한 지침은 Misra에 의해 확립되었지만 Python 및 JVM 언어와 같은 널리 사용되는 언어에는 해당되지 않습니다. NIST에는 테스트 스위트가 있지만 프레임 워크와 생태계는 다소 제한적입니다.
이 시나리오를 고려할 때 개발자는 종종 정적 분석을위한 메커니즘을 재현하거나 새로운 테스트 프레임 워크를 개발하여 반복적 인 작업을 초래합니다. 일부는 Google 코드 스타일 또는 PMD 규칙과 같은 기존 지침을 선택할 수 있지만 접근 방식에 관계없이 상당한 시간은 개념화, 쓰기 및 디버깅 테스트에 항상 소비됩니다.
이 프로젝트는 Gradle을 빌드 시스템으로 사용하며 명령 ./gradlew build 사용하여 구축 할 수 있습니다.
기본 아티팩트를 컴파일하려면 Kotlin/Native 문서에 설명 된대로 전제 조건을 설치해야합니다.
GitHub 패키지 레지스트리에서 호스팅되는 종속성에 액세스하려면 gradle.properties 또는 ~/.gradle/gradle.properties 에 다음을 추가하십시오.
gprUser =<GH username>
gprKey =<GH personal access token> https://github.com/settings/tokens/new에서 개인 액세스 토큰을 생성 할 수 있습니다. 토큰에 read:packages .
생성 된 코드로 인해 프로젝트를 해결 된 수입으로 IDE로 올바르게 가져 오려면 빌드를 한 번 실행 해야합니다.
