save cli

Save-это универсальная структура тестирования командной строки, которую можно использовать для инструментов тестирования, которые работают с кодом, такими как статические анализаторы и компиляторы. Это полностью собственное приложение, не требующее необходимости устанавливать какой -либо SDK.

Что такое спасение?

Проверка и оценка статического анализа (Save)-это экосистема (также см. 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 и Warn: Оптимизация для сценариев, в которых вы хотите исправить файл, и впоследствии проверяйте предупреждения о том, что инструмент не может обратиться за одним прогоном.

Если вы хотите, чтобы несколько плагинов работали в вашем каталоге с использованием одних и тех же тестовых файлов (ресурсов), просто добавьте их все в конфигурацию save.toml :

 [general]
...

[fix]
...

[warn]
...

[other plugin]
...

Сохранить предупреждения DSL

Вы можете прочитать больше о warn plugin Wantn

Как настроить

Save имеет интерфейс командной строки, который позволяет запускать как фреймворк, так и ваш исполняемый файл. Ваша основная задача - настройка вывода вашего статического анализатора, чтобы сохранение могла проверить, была ли соответствующая ошибка помечена в правильной строке тестового кода.

Чтобы гарантировать, что предупреждение является точным для сохранения, ваш статический анализатор должен вывести результат либо в Stderr/STDOUT, либо указанный файл журнала (например, в формате SARIF).

Вы можете настроить общее поведение SAVE с помощью аргументов командной строки или с помощью файла конфигурации с именем save.properties . Этот файл должен быть расположен в том же каталоге, что и конфигурация корневого теста, save.toml .

Для получения полного списка параметров, которые могут быть переданы для сохранения через командную строку или файл save.properties , см. В таблице параметров или выполните команду save --help . Имейте в виду, что варианты с выбором чувствительны к случаям.

Структура сохранения автоматически обнаружит ваши тесты, запускает свой анализатор, рассчитывает скорость прохождения и результаты обратных тестов в ожидаемом формате.

Обнаружение теста и файл save.toml

Чтобы включить сохранение для обнаружения ваших тестовых люксов, вы должны разместить файл save.toml в каждом каталоге, содержащий тестовые наборы . Важно отметить, что эти файлы конфигурации наследуют конфигурации от родительских каталогов.

Хотя большинство полей можно оставить неопределенными на более низких уровнях и может наследовать значения от верхних уровней, вы должны быть осторожными. Некоторые поля в разделе [general] являются обязательными для выполнения, поэтому вам необходимо указать их по крайней мере в одном файле конфигурации в цепочке наследования для тестов, которые предназначены для запуска. Проверьте, какие поля являются обязательными.

Например, с иерархией следующей каталога:

 | A
  | save.toml
  | B
    | save.toml

save.toml в каталоге B будет наследовать настройки и свойства из каталога A.

Имейте в виду, что сохранение будет обнаружить все файлы с помощью Postfix «тест» и автоматически использовать конфигурации из файла save.toml , присутствующего в том же каталоге (или унаследован от родителей). Тесты названы в соответствии с именем ресурса тестового файла, за исключением суффикса «тест». Если сохранение обнаруживает файл с постфиксом «тест» в тестовых ресурсах и не может найти какие -либо конфигурации save.toml в иерархии каталога , он принесет ошибку.

Например, приведенный ниже сценарий недействителен и вызовет ошибку, так как структура сохранения не может найти файл конфигурации save.toml :

 | A
  | B
  | myTest.java

Как упоминалось ранее, save.toml необходим для настройки тестов. В идеале должен быть один файл конфигурации для каждого каталога, содержащего тесты, устанавливая отношения от одного ко многим. Мы называем эти каталоги как test suites .

Обоснование, стоящее за наличием одного файла конфигурации для одного набора тестов, состоит в том, чтобы избежать избыточных конфигураций в одном и том же испытательном наборе.

Save.toml файл конфигурации

Конфигурация сохранения использует формат TOML, работающий под проектом KTOML. Как упомянуто выше, 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 - is is directory с сохранением бинарного):

$ 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 .

Цель статического анализа проверки и оценки (Save)

Цель статического анализа проверки и оценки (Save)

Цель сохранения

Вступление

Использование статических анализаторов является неотъемлемой частью процесса разработки для каждого программного продукта. В то время как разработчики программного обеспечения могут писать различные тесты и добиться хорошего тестового покрытия, человеческая ошибка остается неизбежной. Такие ошибки могут привести к значительным финансовым потерям для компаний. Статический анализ программы помогает выявлять и исправлять ошибки и проблемы, которые могут не обнаруживаться только с помощью только с помощью проверки компилятора.

Статический анализ бывает в различных формах и служит разным целям. Он может включать простой анализ с использованием AST (Abstract Syntax Tree) или углубления в более сложные процедуры, такие как CFA (анализ контрольного потока), межпроцедурный анализ или контекстный анализ. Статические анализаторы могут оценить стиль кода, определить потенциальные проблемы времени выполнения в логике приложения, обнаруживать запахи кода и предлагать лучшие практики. Тем не менее, остается отсутствие ясности в отношении основных функций статических анализаторов. Как их эффективность может быть количественно определено? Какие критерии определяют их принятие? Какие функции необходимы для разработчиков, создающих новый анализатор? Несмотря на многолетние развития статического анализатора, эти вопросы остаются в значительной степени без ответа.

Проблема

В начале их путешествия по разработке каждый создатель статического анализатора начинает с выявления видов проблем, которые их инструмент будет нацелен. Это часто требует поиска существующих списков потенциальных проблем или тестовых пакетов, которые могут направлять процесс разработки, особенно если следовать подходу 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 с разрешенным импортом.