Ние активно използваме платформата в нашата работа soundQube за поддържане на високо ниво на качеството на кода. При интегриране на един от проектите, написани в VueJs+Typescript, възникнаха проблеми. Затова бих искал да ви разкажа по-подробно как успяхме да ги разрешим.

В тази статия ще говорим, както писах по-горе, за платформата SonarQube. Малко теория - какво е това като цяло, за тези, които чуват за него за първи път:

soundQube (бивш Хидролокатор) е платформа с отворен код за непрекъсната проверка и измерване на качеството на кода.
Поддържа анализ на код и откриване на грешки съгласно правилата на стандартите за програмиране MISRA C, MISRA C++, MITER/CWE и CERT Secure Coding Standards. Може също така да разпознава грешки от списъка Топ 10 на OWASP и Топ 25 на CWE/SANS с програмни грешки.
Въпреки факта, че платформата използва различни готови инструменти, SonarQube намалява резултатите до едно табло за управление, запазвайки история на изпълненията и по този начин ви позволява да видите общата тенденция на промени в качеството на софтуера по време на разработката.

Повече подробности можете да намерите на официален сайт

Поддържат се голям брой езици за програмиране. Съдейки по информацията от линка по-горе, това са повече от 25 езика. За да поддържате определен език, трябва да инсталирате съответния плъгин. Версията на общността включва плъгин за работа Javascript (включително typeсript), въпреки че уикито казва обратното. Отзад Javascript плъгин отговори SonarJS, за Typescript SonarTS съответно.

Официалният клиент се използва за изпращане на информация за покритие sonarqube-скенер, който, използвайки настройките от довереник-file, изпраща тези данни на сървъра soundQube за по-нататъшна консолидация и агрегиране.

За Javascript има npm обвивка. И така, нека започнем стъпка по стъпка внедряването soundQube в Vue-използване на проект написан на пишеща машина.

За да разположите сървър soundQube да се възползваме докер-ново съобщение.

сонар.yaml:

version: '1'
    services:
        simplesample-sonar:
            image: sonarqube:lts
            ports:
                - 9001:9000
                - 9092:9092
            network_mode: bridge

Стартиране:

docker-compose -f sonar.yml up

След това soundQube ще бъде на разположение на: http://localhost:9001 .

В него все още няма проекти и това е справедливо. Ние ще коригираме тази ситуация. Взех официалния примерен проект за VueJS+TS+Jest. Нека го наведем към себе си:

git clone https://github.com/vuejs/vue-test-utils-typescript-example.git

Първо трябва да инсталираме клиента soundQubeкоето се нарича сонар-скенерза NPM има обвивка:

yarn add sonarqube-scanner

И веднага добавете командата към скриптове да работи с него.

package.json:

{
 … 
   scripts: {
      ...
      "sonar": "sonar-scanner"
      ...
   },
 …
}

След това, за да работи скенерът, трябва да зададете настройките на проекта в специален файл. Да започнем с основите.

sonar-project.properties:

sonar.host.url=http://localhost:9001

sonar.projectKey=test-project-vuejs-ts
sonar.projectName=Test Application (VueJS+TS)

sonar.sources=src
# sonar.tests=
sonar.test.inclusions=src/**/*tests*/**
sonar.sourceEncoding=UTF-8

sonar.host.url - адрес Хидролокатор'A;
sonar.projectKey – уникален идентификатор на проекта на сървъра Хидролокатор'A;
sonar.projectName – името му, то може да бъде променено по всяко време, тъй като проектът се идентифицира с projectKey;
сонар.източници – папка с източници, обикновено това SRC, но може да бъде всичко. Тази папка е зададена спрямо основната папка, която е папката, от която се стартира скенерът;
сонар.тестове – параметър, който върви в тандем с предишния. Това е папката, в която се намират тестовете. В този проект няма такава папка и тестът се намира до компонента, който се тества в папката 'тест', така че засега ще го игнорираме и ще използваме следващия параметър;
сонар.тест.включвания – път за тестове с помощта на маска, може да има няколко елемента, изброени разделени със запетаи;
sonar.sourceEncoding – кодиране за изходни файлове.

За първото стартиране на скенера всичко е готово, с изключение на основното предшестващо действие: стартиране на самия тестов двигател, за да може да генерира информация за покритието, която скенерът ще използва впоследствие.

Но за да направите това, трябва да конфигурирате тестовата машина да генерира тази информация. В този проект тестовият двигател е има. А настройките му са в съответния раздел на файла package.json.

Нека добавим тези настройки:

"collectCoverage": true,
"collectCoverageFrom": [
      "src/**/*",
      "!src/main.ts",
      "!src/App.vue",
      "!src/**/*.d.*",
      "!src/**/*__tests__*"
],

Тоест, задаваме самия флаг за необходимостта от изчисляване на покритието и източника (заедно с изключения), въз основа на който ще се формира.

Сега нека изпълним теста:

yarn test

Ще видим следното:

Причината е, че в самия компонент няма код. Нека поправим това.

HelloWorld.vue:

...
methods: {
    calc(n) {
      return n + 1;
    }
  },
mounted() {
  this.msg1 = this.msg + this.calc(1);
},
...

Това ще бъде достатъчно за изчисляване на покритието.

След рестартиране на теста ще се уверим в това:

На екрана трябва да видим информация за покритието и в папката на проекта ще бъде създадена папка обхват с информация за тестовото покритие в универсален формат LCOV (LTP GCOV разширение).

Gcov е свободно разпространявана помощна програма за изследване на покритието на кода. Gcov генерира точния брой изпълнения за всеки израз в програма и ви позволява да добавяте анотации към изходния код. Gcov идва като стандартна помощна програма като част от GCC пакета.
Lcov - графичен интерфейс за gcov. Той събира gcov файлове за множество изходни файлове и създава набор от HTML страници с код и информация за покритието. Страниците също се генерират, за да улеснят навигацията. Lcov поддържа покритие на низове, функции и разклонения.

След като тестовете приключат, информацията за покритието ще бъде разположена в coverage/lcov.info.
Трябва да кажем Хидролокатор„Откъде мога да го взема? Затова нека добавим следните редове към неговия конфигурационен файл. Но има един момент: проектите могат да бъдат многоезични, тоест в папката SRC има изходни кодове за няколко езика за програмиране и принадлежност към един или друг, а от своя страна използването на един или друг плъгин се определя от неговото разширение. И информацията за покритие може да се съхранява на различни места за различни езици за програмиране, така че всеки език има своя собствена секция за настройка на това. Нашият проект използва написан на пишеща машина, така че имаме нужда от раздел с настройки само за него:

sonar-project.properties:

sonar.typescript.coveragePlugin=lcov
sonar.typescript.lcov.reportPaths=coverage/lcov.info

Всичко е готово за първото пускане на скенера. Бих искал да отбележа, че проектът е Хидролокатор'e се създава автоматично при първото стартиране на скенера за даден проект. В следващите времена ще се натрупва информация, за да се види динамиката на промените в параметрите на проекта във времето.

И така, нека използваме командата, създадена по-рано в package.json:

yarn run sonar

Забележка: можете също да използвате параметъра -X за по-подробно регистриране.

Ако скенерът е стартиран за първи път, първо ще бъде изтеглен двоичният файл на самия скенер. След това стартира и започва да сканира сървъра Хидролокатор'a за инсталирани добавки, като по този начин се изчислява поддържаният език. Зареждат се и различни други параметри за работата му: качествени профили, активни правила, хранилище на метрики, сървърни правила.

Забележка: Няма да се спираме на тях подробно в рамките на тази статия, но винаги можете да се свържете с официални източници.

След това започва анализът на папката SRC за наличие на изходни файлове за всички (ако не е изрично посочен конкретен) поддържани езици, с последващото им индексиране.

Следват различни други анализи, върху които не се фокусираме в тази статия (например линтинг, откриване на дублиране на код и др.).

В самия край на работата на скенера цялата събрана информация се обобщава, архивира и изпраща на сървъра.

След това вече можем да видим какво се е случило в уеб интерфейса:

Както виждаме, нещо работи и дори показва някакво покритие, но не съвпада с нашето има- доклад.

Нека да го разберем. Нека разгледаме проекта по-подробно, щракнете върху стойността на покритието и „пропаднете“ в подробен файлов отчет:

Тук виждаме, в допълнение към основния, прегледан файл HelloWorld.vue, има и файл main.ts, което разваля цялата картина на покритието. Но как така го изключихме от изчисляването на покритието. Да, всичко е точно, но беше на ниво има, но скенерът го индексира, така че се озова в неговите изчисления.

Нека поправим това:

sonar-project.properties:

...
sonar.exclusions=src/main.ts
...

Бих искал да направя пояснение: в допълнение към папките, които са посочени в този параметър, се добавят и всички папки, изброени в параметъра сонар.тест.включвания.

След като стартираме скенера, виждаме правилната информация:

Нека да разгледаме следващата точка - Качествени профили. По-горе говорих за поддръжка Хидролокаторна няколко езика едновременно. Точно това виждаме. Но знаем, че нашият проект е написан TS, така че защо да натоварвате скенера с ненужни манипулации и проверки. Ще зададем езика за анализ, като добавим още един параметър към конфигурационния файл Хидролокатор„А:

sonar-project.properties:

...
sonar.language=ts
...

Нека пуснем отново скенера и да видим резултата:

Покритието беше напълно изчезнало.

Ако погледнем дневника на скенера, можем да видим следния ред:

Тоест файловете на нашите проекти просто не бяха индексирани.

Ситуацията е следната: официално се поддържа VueJs е в плъгина SonarJSкой е отговорен за Javascript.

Но тази поддръжка не е в плъгина SonarTS за TS, за което беше отворен официален билет в инструмента за проследяване на грешки Хидролокатор„А:

Ето някои отговори на един от представителите на разработчиците на SonarQube, потвърждаващи този факт.

Но всичко ни се получи, възразявате вие. Да, така е, нека опитаме малко „хак“.
Ако има подкрепа .vue-файлове Хидролокатор„О, тогава нека се опитаме да му кажем да ги смята за написан на пишеща машина.

Нека добавим параметър:

sonar-project.properties:

...
sonar.typescript.file.suffixes=.ts,.tsx,.vue
...

Да стартираме скенера:

И, готово, всичко се връща към нормалното и само с един профил за написан на пишеща машина. Тоест успяхме да решим проблема в поддръжката VueJs+TS за soundQube.

Нека се опитаме да отидем по-далеч и да подобрим малко информацията за покритието.

Какво сме направили досега:

добавени към проекта Хидролокатор-скенер;
настройвам има за генериране на информация за покритие;
конфигуриран Хидролокатор-скенер;
реши проблема с поддръжката .vue-файлове + написан на пишеща машина.

В допълнение към тестовото покритие има и други интересни полезни критерии за качество на кода, например дублиране на кода и броя на редовете (включени в изчисляването на коефициентите, свързани със сложността на кода) на проекта.

В текущата реализация на плъгина за работа с TS (SonarTS) няма да работи CPD (детектор за копиране и поставяне) и броене на редове код .vue-файлове.

За да създадете синтетична ситуация на дублиране на код, просто дублирайте компонентния файл с различно име и също го добавете към кода main.ts фиктивна функция и я дублирайте с различно име. За да проверите за дублиране, както в .vue, и в .ts -файлове.

main.ts:

...
function name(params:string): void {
  console.log(params);
}
...

За да направите това, трябва временно да коментирате конфигурационния ред:

sonar-project.properties:

...
sonar.exclusions=src/main.ts
...

Нека рестартираме скенера заедно с тестването:

yarn test && yarn run sonar

Разбира се, покритието ни ще падне, но сега това не ни интересува.

По отношение на дублиране на редове код, ще видим:

За проверка ще използваме CPD-полезност – jscpd:

npx jscpd src

За редове код:

Може би това ще бъде решено в бъдещи версии на приставки SonarJS(TS). Бих искал да отбележа, че те постепенно започват да обединяват тези два плъгина в един SonarJS, което според мен е правилно.

Сега исках да обмисля възможността за подобряване на информацията за покритието.

Досега можем да видим тестовото покритие в проценти за целия проект и по-специално за файловете. Но е възможно този показател да се разшири с информация за количеството единица-тестове за проекта, както и в контекста на файлове.

Има библиотека, която може има-преобразуване на отчета във формат за Хидролокатор„А:
общи тестови данни - https://docs.sonarqube.org/display/SONAR/Generic+Test+Data.

Нека инсталираме тази библиотека в нашия проект:

yarn add jest-sonar-reporter

И го добавете към конфигурацията има:

package.json:

…
"testResultsProcessor": "jest-sonar-reporter"
…

Сега нека изпълним теста:

yarn test

След което ще бъде създаден файл в корена на проекта test-report.xml.

Нека го използваме в конфигурацията Хидролокатор„А:

sonar-project.properties:

…
sonar.testExecutionReportPaths=test-report.xml
…

И рестартирайте скенера:

yarn run sonar

Нека да видим какво се е променило в интерфейса Хидролокатор„А:

И нищо не се е променило. Факт е, че Sonar не счита файловете, описани в доклада на Jest, за файлове единица-тестове. За да коригираме тази ситуация, използваме конфигурационния параметър Хидролокатор сонар.тестове, в който изрично ще посочим папките с тестове (засега имаме само една):

sonar-project.properties:

…
sonar.tests=src/components/__tests__
…

Нека рестартираме скенера:

yarn run sonar

Нека да видим какво се е променило в интерфейса:

Сега видяхме броя на нашите единица-тестове и след неуспешно щракване вътре можем да видим разпределението на това число между файловете на проекта:

Заключение

И така, разгледахме инструмент за непрекъснат анализ soundQube. Успешно интегрирахме в него проект, написан в VueJs+TS. Поправени са някои проблеми със съвместимостта. Увеличихме информационното съдържание на индикатора за тестово покритие. В тази статия разгледахме само един от критериите за качество на кода (може би един от основните), но soundQube поддържа други критерии за качество, включително тестове за безопасност. Но не всички от тези функции са напълно налични в общност - версии. Една от интересните и полезни функции е интеграцията soundQube с различни системи за управление на хранилища за кодове, като GitLab и BitBucket. За предотвратяване заявка за изтегляне (сливане) на сливане'a към основния клон на хранилището, когато покритието е влошено. Но това е история за съвсем различна статия.

PS: Всичко описано в статията под формата на код е достъпно в моята вилица.

В анкетата могат да участват само регистрирани потребители. Впиши се, Моля те.