sonar gherkin plugin

Sonarqube Cucumber Gherkin 분석기

부인 성명

이 플러그인을 계속 유지하고 싶지 않습니다. 당신이 인수하고 싶다면 자유롭게 핑을하십시오.

설명

이 Sonarqube 플러그인은 오이 Gherkin 기능 파일을 분석합니다.

• 메트릭 계산 : 코드 줄, 시나리오 수 등.
• 40 개가 넘는 수표를 통해 잠재적 인 버그 및 코드 냄새를 찾기 위해 다양한 지침을 확인합니다.
• 자신의 수표를 작성하는 기능을 제공합니다

용법

1. Sonarqube를 다운로드하여 설치하십시오
2. 오이 Gherkin 플러그인을 직접 다운로드하여 설치하십시오. 최신 버전은 Sonarqube 6.7+와 호환됩니다.
3. 좋아하는 스캐너 설치 (Sonarqube Scanner, Maven, Ant 등).
4. 코드를 분석하십시오

Maven

기능 파일은 소스 코드 디렉토리가 아니라 테스트 디렉토리에있을 수 있습니다. 기본적으로 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 분석기에서 규칙을 사용할 수 있도록 풀 요청을 자유롭게 작성하십시오.

당신은 커뮤니티에 도움이 될 수 있지만 시간이나 글을 쓸 시간이없는 새로운 규칙을 생각하고 있습니까? 귀하의 규칙을 고려할 수있는 문제를 자유롭게 작성하십시오.

메트릭

진술

단계 수.

기능

시나리오 및 시나리오 윤곽선 수.

수업

기능 수.

사용 가능한 규칙

• "FixMe"태그를 처리해야합니다
• "TODO"태그를 처리해야합니다
• 모든 주석은 일관되게 형식화되어야합니다
• 그리고 그러나 만약 주어진/다음/그 다음 접두사 대신 접두사를 사용해야합니다.
• UTF-8 파일에는 바이트 주문 마크 (BOM)를 사용해서는 안됩니다.
• 주어진 주어진 단계는 배경에 추가되어야합니다
• 복제 된 단계를 제거해야합니다
• 엔드 라인 문자는 일관성이 있어야합니다
• 예제 데이터 테이블에는 데이터가 두 개 이상 포함되어야합니다.
• 기능은 동일한 언어로 작성해야합니다
• 기능에는 설명이 있어야합니다
• 기능에는 이름이 있어야합니다
• 기능에는 고유 한 이름이 있어야합니다
• 기능에는 너무 많은 시나리오가 포함되어서는 안됩니다
• 시나리오를 정의하지 않는 기능을 제거해야합니다.
• 파일 이름은 이름 지정 규칙을 준수해야합니다
• 파일은 마지막에 빈 새 라인을 포함해야합니다.
• 기능을 정의하지 않는 파일을 제거해야합니다.
• 주어진 단계는 정규 표현을 따라야합니다
• 주어진/시기/다음 단계는 올바른 순서로 정의되어야합니다
• 선은 후행의 공백으로 끝나지 않아야합니다
• 누락 된 데이터 테이블 열을 추가해야합니다
• 부여되지 않은 단계는 배경에서 벗어나야합니다
• 화이트리스트의 태그 만 사용해야합니다
• 의견에 대한 정규 표현
• 시나리오는 각 주어진/시기/그 다음 단계 유형 중 하나 이상을 정의해야합니다.
• 시나리오에는 이름이 있어야합니다
• 시나리오에는 고유 한 이름이 있어야합니다
• 시나리오에는 너무 많은 단계가 포함되어 있지 않아야합니다
• 단계를 정의하지 않는 시나리오를 제거해야합니다.
• 소스 코드는 제대로 들여 쓰기해야합니다
• 철자 실수는 수정되어야합니다
• 별 (*) 단계 접두사를 사용해서는 안됩니다
• 계단 문장이 너무 길어서는 안됩니다
• 알려지지 않은 유형의 단계를 사용해서는 안됩니다
• 테이블 캐릭터를 사용해서는 안됩니다
• 태그는 올바른 레벨에서 정의해야합니다
• 태그는 이름 지정 규칙을 준수해야합니다
• 예제에 태그를 설정해서는 안됩니다
• 그런 다음 단계는 정규 표현을 따라야합니다
• 시나리오 당 1 개의 단계가 있어야합니다
• 사용하지 않은 변수를 제거해야합니다
• 쓸모없는 태그를 제거해야합니다
• 단계가 정규 표현을 따라야하는 경우
• 문구는 비즈니스 수준에 남아 있어야합니다