Quality Gates
Quality Gates

Quality Gates

Другое 13.09.2020

Quality Gates – это набор условий, которым должен соответствовать проект, прежде чем он сможет претендовать на релиз. Концепция Quality Gates возникла еще в 1986 году и изначально применялась для контроля качества в автомобильной промышленности. Это лучший способ обеспечить соблюдение всех стандартов и их регулирование на проекте. Quality Gates можно определить как набор пороговых показателей, таких как Code Coverage, технический долг, количество блокирующих проблем и уязвимостей, дубликаты кода и т.д.

Linters

Проверка кода линтерами помогает избежать многих ошибок еще на этапе написания кода. Анализ синтаксиса и структуры кода проводится автоматически и при обнаружении нарушений правил написания кода, выводится соответствующее сообщение в консоль. Такой подход позволяет избежать очень много типовых ошибок на ранних этапах разработки, а так же значительно сэкономить время и силы на код-ревью.

Первый линтер был написан Стивеном Джонсоном в 1978 году, когда он работал в операционной системе Unix в Bell Labs. После появилось много других линтеров на разные языки программирования с различными настройками, позволяющие статически анализировать код, используя настройки конфигурации и проверяя соответствие кода заданным проектным требованиям по стилю и правилам безопасности.

Основные задачи линтеров:

1. Статический анализ – автоматизированное программное обеспечение проходится по Вашему коду (не выполняя его) и тем самым статически проверяет на наличие ошибок, например, табуляция, нейминг, утечки памяти, соответствие правилам Code standards, которые приняты на проекте и многое другое.

Code standards – это набор правил и соглашений, используемых при написании исходного кода на определенном проекте. Это обеспечивает читаемость кода, сохраняет одинаковую стилизацию по всему проекту и ускоряет процесс адаптации новых сотрудников.

2. Проблемы с безопасностью – есть специальные плагины, например eslint-plugin-security для node js, которые позволяют выявить слабые места безопасности, например, использование команды eval, вызов дочерних процессов, импорт модулей с передачей в соответствующую команду чего-то, отличающегося от строкового литерала и т.д.

3. Улучшения производительности – есть несколько правил по написанию кода, которые позволят улучшить производительность, например в CSS – селектор * или слишком длинная цепочка селекторов
#header .header__inner nav ul.nav-menu li:hover a {}
 могут ухудшить скорость загрузки страницы.

4. Упрощения процесса Code review – поскольку описки и другие банальные ошибки будут исправлены до процесса Code review, во время просмотра Pull Request не будет необходимости тратить время на проверку синтаксиса кода и соответствие его базовым кодовым стандартам, а можно будет сосредоточиться на анализе выбранного решения, что значительно сэкономит время всех участников процесса review.

5. Делает код читаемым. Если стиль написания кода не изменяется от файла к файлу и в различных функциях – это делает код читаемым и легким для восприятия.

Рассмотрим пример такого кода:

function sayHello(name){
alert("Hello " + name);
}

name = "Albus Dumbledore";
sayHello(name)

После проверки линтерами вы увидите следующие ошибки:

Ожидается пробел между ‘)’ и ‘{‘ function sayHello(name){

Ожидается ‘use strict’ перед ‘alert’. alert("Hello " + name);

Необъявленная переменная ‘name’ name = "Albus Dumbledore";

Необъявленная переменная ‘name’ sayHello(name)

Ожидается ‘;’ в конце строки sayHello(name)

Pre-commit

Для уверенности в том, что все синтаксические ошибки исправлены на максимально раннем этапе – рекомендуют запускать линтеры в обязательном порядке перед каждым коммитом. В таком случае пока все ошибки не будут исправлены – система не позволит Вам сделать коммит в репозиторий.

Для создания Pre-commit хука установим пакет husky и включим хук в package.json:

{
  "husky": {
    "hooks": {
      "pre-commit": "eslint src --fix"
    }
  }
}

Также рекомендуется добавление запуска Unit Tests в прекоммит хук, но об этой теме мы поговорим далее.

Unit Tests

Unit Tests – это тестирование наименьшей части приложения – отдельной функции в изоляции от внешней логики. Задача каждого отдельного теста проверить, что при попадании на вход функции возвращается ожидаемый результат. Тесты должны быть максимально изолированы от приложения, для чего используются моки данных и функций.

Написание каждого теста проходит в 3 этапа:

  • Создание нужных для теста данных
  • Вызов тестируемой части кода
  • Проверка результатов – сравнивание с ожидаемыми

Для unit-тестирования в Angular приложениях используется фреймворк Jasmine, для запуска тестов в разных браузерах или в headless mode используется Karma.

Структура тестов:

describe('tests group', () => {
    beforeEach(() => {...});

    it('test description', async(() => {
        expect(...).toBe(...);
    }));

    ...
});

Функция describe() объединяет в себе группу взаимосвязанных тестов, где первый параметр (string) – текстовое описание группы, второй параметр – функция, которая содержит конфигурацию и набор тестов.

Функция it() описывает каждый тест в отдельности, она принимает 2 параметра – тестовое описание функции и функцию теста.

Функция beforeEach() используется для того, что бы задать исходное состояние перед каждой функцией it().

Функция expect() служит для проверки результатов, она принимает параметр – результат и позволяет его проверить одним из способов (toBeTruthy, toEqual, toContain …)

Unit тестов всегда наибольшее количество, так как они маленькие, не занимают много времени на написание и поддержку, не требуют много ресурсов и в кратчайшие сроки позволяют разработчикам обнаружить ошибки в коде еще на ранних этапах разработки.

Code Coverage – одна из оценок качества тестирования приложения. Она показывает на сколько хорошо приложение покрыто тестами в процентном соотношении.

Code review

Code review – это анализ написанного кода другими разработчиками перед добавлением кода в общую ветку.

Основные задачи процесса Code review:

  • Выявить ошибки в коде
  • Улучшить качество кода
  • Обмен знаниями между членами команды – об измененном функционале

Подготовка к Code review:

  • Изменения должны иметь узкую, четко определенную и замкнутую область, которую они полностью охватывают
  • Более короткие изменения предпочтительнее более длительных. Если вносятся существенные изменения в более чем ~ 5 файлов, или на созданиe Pull Request уходит более 1-2 дней, или на рассмотрение требуется более 20 минут, можно попробовать разделения PR на несколько автономных.
  • Перед созданием PR запустите все линтеры кода и Unit тесты для того, что бы найти самые примитивные и распространенные ошибки.

Анализ кода с помощью SonarQube

SonarQube — это платформа с открытым исходным кодом, предназначенная для непрерывного анализа и измерения качества кода. В SonarQube есть набор правил для анализа исходного кода во время компиляции с целью выявления потенциальных уязвимостей, ошибок, анти-шаблонов и плохих методов кодирования. Также можете создать новые Quality Gates для своих проектов и определять индивидуальные пороговые значения.

При запуске SonarQube он определит, соответствует ли код всем установленным вами порогам качества, в случае если какой-то из Quality Gates нарушен – автоматическая сборка проекта завалится.

Automation Tests

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

Automation тесты делятся на 3 уровня: Unit tests, Integration и GUI (Graphical User Interface). Пирамида автоматизированного тестирования наглядно показывает сколько тестов какого уровня должно присутствовать. Unit tests – самые быстрые и простые тесты в написании, соответственно и самые дешевые, а это значит, что их должно быть больше всего на проекте. Интеграционные тесты предназначены для проверки связи между компонентами, а также взаимодействия с различными частями системы. GUI тестирование программного обеспечения проверяет графический интерфейс пользователя, а именно то, что при взаимодействии пользователя с приложением, например клик по кнопке или отправлении формы – пользователь получит ожидаемый результат. Эти тесты являются самыми сложными в написании и поддержке, требуют наибольшее время для прохождения, потому их количество должно быть наименьшее, в сравнении с другими тестами. GUI тесты следует запускать уже после того, как убедитесь, что Unit и Integration тесты прошли успешно.
Automation Tests

Automation тесты позволяют:

  • Снизить затраты на разработку проекта
  • Увеличить test coverage
  • Повысить точность тестирования
  • Увеличить скорость тестирования и разработки проекта
  • Быстро обнаружить и и исправлять дефекты

Чем раньше мы выявим проблемы, тем проще и дешевле их решить – используя возможности статического анализа кода, разработчики могут получать раннюю обратную связь об изменениях, находить и выявлять ошибки на самых ранних этапах.

Источники: Habr, Medium, Codereadability, Javarush, Samirbehara, Mindk

Поделиться

Отправить ответ

avatar
  Получать новые комментарии  
Уведомлять о новых комментариях