Sonarqube Cucumber Gherkin Analyzer
Отказ от ответственности
Я не хочу продолжать поддерживать этот плагин. Не стесняйтесь, если хотите взять на себя.
Описание
Этот плагин Sonarqube анализирует файлы функций огурца Gherkin и:
- Комплекты показателей: строки кода, количество сценариев и т. Д.
- Проверяет различные рекомендации, чтобы выяснить потенциальные ошибки и кодовые запахи через более 40 проверок
- Предоставляет возможность писать свои собственные чеки
Использование
- Скачать и установить Sonarqube
- Установите плагин Gherkin Gherkin с прямой загрузкой. Последняя версия совместима с Sonarqube 6.7+.
- Установите свой любимый сканер (сканер Sonarqube, Maven, Ant и т. Д.)
- Проанализируйте свой код
Мавен
Вполне вероятно, что ваши файлы функций находятся не в каталогах исходного кода, а в каталогах тестирования. По умолчанию Sonarqube не анализирует эти тестовые каталоги. Таким образом, вы должны явно сказать Sonarqube также проанализировать тестовые каталоги, содержащие ваши файлы функций.
Допустим, структура вашего проекта:
pom.xml
src
|-- main
|-- java
|-- resources
|-- test
|-- java
|-- resources
|-- features
|-- my-feature.feature
|-- my-other-feature.feature
В вашем файле POM вам нужно добавить:
<properties>
<sonar.sources>pom.xml,src/main/java,src/main/resources,src/test/resources/features</sonar.sources>
</properties>
Пользовательские проверки
Вы думаете о новых ценных правилах? Версия 1.0 или больше предоставляет API для написания собственных пользовательских проверок. Образец плагина с подробными объяснениями доступен здесь. Если ваши пользовательские правила могут принести пользу сообществу, не стесняйтесь создавать запрос на тягу, чтобы сделать правило доступным в анализаторе Gherkin Gherkin.
Вы думаете о новых правилах, которые могут принести пользу сообществу, но у вас нет времени или навыков, чтобы написать их? Не стесняйтесь создавать проблему для ваших правил, которые будут рассматриваться.
Метрики
Заявления
Количество шагов.
Функции
Количество сценариев и сценариев.
Классы
Количество функций.
Доступные правила
- Теги "fixme" должны быть обработаны
- Теги "todo" должны быть обработаны
- Все комментарии должны быть отформатированы последовательно
- И и но префиксы следует использовать вместо избыточного данного/когда/затем префиксы
- Байт-оценка (BOM) не должна использоваться для файлов UTF-8
- Общие задачи должны быть добавлены на фоновой
- Дублированные шаги должны быть удалены
- Конечные символы должны быть последовательными
- Примеры таблицы данных должны содержать данные, по крайней мере, два строки данных
- Особенности должны быть написаны на том же языке
- Функции должны иметь описание
- Функции должны иметь имя
- Особенности должны иметь уникальное имя
- Особенности не должны содержать слишком много сценариев
- Особенности, которые не определяют какого -либо сценария, должны быть удалены
- Имена файлов должны соответствовать соглашению об именах
- Файлы должны содержать пустую новую строку в конце
- Файлы, которые не определяют какую -либо функцию, должны быть удалены
- Данные шаги должны следовать регулярному выражению
- Дано/когда/затем шаги должны быть определены в правильном порядке
- Линии не должны заканчиваться
- Столбцы с отсутствующими таблицами данных должны быть добавлены
- Неизженные шаги должны быть перемещены на фоне
- Должны использоваться только теги из белого списка
- Регулярное выражение в комментарии
- Сценарии должны определить по крайней мере по одному из приведенных/когда/затем тип шага
- Сценарии должны иметь имя
- Сценарии должны иметь уникальное имя
- Сценарии не должны содержать слишком много шагов
- Сценарии, которые не определяют какого -либо шага, должны быть удалены
- Исходный код должен быть должным образом отступо
- Ошибки орфографии должны быть исправлены
- Star (*) Step Prefixes не следует использовать
- Шаг предложения не должны быть слишком длинными
- Шаги неизвестного типа не должны использоваться
- Символы таблиц не должны использоваться
- Теги должны быть определены на правильном уровне
- Теги должны соответствовать соглашению об именах
- Теги не должны быть установлены на примерах
- Тогда шаги должны следовать регулярному выражению
- Должен быть один, когда шаг за сценарий
- Неиспользуемые переменные должны быть удалены
- Бесполезные теги должны быть удалены
- Когда шаги должны следовать регулярному выражению
- Формулировка должна оставаться на бизнес -уровне
