Результаты ежегодного опроса среди разработчиков от JetBrains https://www.jetbrains.com/lp/devecosystem-2019/. Мне там интересно было посмотреть статистику использования фреймворков для юнит-тестирования. Язык C: GTest - 20%, остальные сильно отстают от него и 50% - None. Язык C++: разработчики более ответственные GTest - 37%, CPPUnit - 25% (доля выросла на 10% по сравнению с прошлым годом), None - 34%, остальные фреймворки сильно меньшую долю имеют.
Написал в блоге про свои эксперименты с мутационным тестированием. В прошлый раз был проект с сетевым сканером для индустриальных сетей и по факту MT не получилось внедрить. В этот раз был проект с микроядром и в ходе MT нашлись непокрытые участки кода.
Еще одно откровение: Желание иметь чистые функции без сайд-эффектов привело к появлению в императивном подходе TDD (Test-Driven Development). По сути он принуждает вас почти насильно писать "чистые функции" и изолировать сайд-эффекты, например, работу с БД, с внешним сервером, в отдельные классы (моки, фэйки), чтобы их можно было легко подменить во время тестирования. Вывод: TDD в императивных языках появилось тоже не от хорошей жизни. В ФП-языках оно не нужно, потому что там итак все функции чистые.
Помню время, когда из всех доступных CI, были только CruiseControl, Дженкинс и может несколько других. Про CI-as-a-service тогда никто и не думал. Сейчас ассортимент доступных CI сильно увеличился, конкуренция в лучшем виде. Доступны и бесплатные CI в облаке и self-hosted версии под свободными лицензияии. На прошлых выходных я потратил немного времени, чтобы посмотреть на самые популярные облачные сервисы CI и ниже самые интересные детали этого обзора.
- многообразие поддерживаемых ОС: теперь поддерживаются не только три популярные ОС (Windows, Linux, Mac OS), но можно и свои другие ОС использовать. Я например давно жду когда кто-нибудь сделает поддержку BSD и дождался. Cirrus CI поддерживает образы с Амазона и Гугл Клауда, поэтому теперь без проблем можно тестировать на FreeBSD и OpenBSD. CircleCI позволяет использовать инстансы с AWS и Azure. Вообще Cirrus CI это моё открытие за все время обзора. Парни решили пересмотреть свой взгляд на CI и написали про это статью. - некоторые CI позволяют параллельный запуск тестов, как например Circle CI (https://circleci.com/docs/2.0/parallelism-faster-jobs/) - многие CI позволяют публиковать результаты тестов и показывают отчёты для них, сравнивают с предыдущими запусками (например Circle CI) - декларативное описание конвейера CI - стандарт де-факто. В Дженкинсе помню долго пытались добавить декларативное описание задач и когда оно появилось, то было сильно глючное (жаловались знакомые девопсы, тестирующие компоненты OpenStack). - помню мне кто-то говорил, что его любимый CI это сервис от Джетбрейнс. Потрогал, действительно неплохой. - многие CI позволяют сохранять артефакты на некоторое время. Оказывается популярный Travis CI в этом отстаёт - там можно выложить артефакты только на внешний сервер.
До этого писал про автоматическое исправление багов на основе машинного обучения, а вчера Амазон анансировал CodeGuru для автоматического ревью кода с помощью машинного обучения, из языков пока поддерживается только Java.
Ян Грэхем (Ian Graham) в своей книге "Объектно-ориентированные методы. Принципы и практика." приводит следующий пример неадекватной формализации требования, выполненной в рамках реального проекта. Одно из требований к системе управления самолетом состояло в том, что при посадке тормозной двигатель малой тяги не должен включаться, пока самолет не коснется взлетно-посадочной полосы. При формализации было принято решение, что условие касания полосы эквивалентно вращению колес шасси самолета — ведь при этом колеса должны войти с ней в контакт. Все работало хорошо, пока однажды самолету не пришлось садиться на полосу после сильного ливня, покрытую водой, по которой колеса начали скользить. В результате тормозной двигатель не включился, и самолет выехал за пределы полосы.
Ядро Linux это один из самых старых и масштабных opensource проектов. В каждом релизе участвуют около 1.5к разработчиков из 200-250 компаний. Последняя версия ядра содержит 24,766,703 строк кода. Ядро используется повсеместно телефоны Android (2e9 пользователей), облачные сервера, настольные системы, ноутбуки, машины, а также в критически важной инфраструктуре: атомные подводные лодки, Большой Андронный Коллайдер, Международная Космическая Станция и т.д. Казалось бы очевидно, что ПО с таким количеством пользователей должно cоответствующим образом тестироваться и иметь налаженный процесс выпуска качественных релизов. Но до сих пор процесс тестирования являлся фрагментированным и каждая компания, которая разрабатывала продукты с использованием Linux ядра, тестировала их самостоятельно, а патчи с исправлением проблем при возможности разработчики возвращали в основную ветку ядра. Для выпуска нового релиза ядра нет формальных процедур тестирования.
Сотрудник Гугла Дмитрий Вьюков долгое время занимался фаззинг-тестированием ядра и последние его доклады на конференциях Linux-разработчиков посвящены фрагментации разработки и огромному количеству неисправленных проблем, которые были найдены с помощью его инструмент для фаззинга ядра syzcaller. Он пытается донести до сообщества разработчиков, что у ядра Linux есть слабое место: плохое тестирование.
Некоторые из его докладов:
- syzbot: and the tale of thousand kernel bugs Слайды, Видео - Reflections on kernel development process, quality and testing Слайды, Видео
Но в ближайшее время возможно текущее положение с тестированием может поменяться и одним из главных признаков этого является то, что KernelCI, среда автоматического тестирования ядра Linux, становится частью проекта Linux Foundation.
На последней конференции Linux Kernel Plumbers одной из самых обсуждаемых тем была автоматизация тестирования ядра Linux. Ведущие компании-разработчики ядра Linux объединили свои усилия в рамках одной среды тестирования: KernelCI и теперь KernelCI стал проектом Linux Foundation. Пока в KernelCI регулярно тестируются сборка ядра в разных конфигурациях и их загрузка на множестве поддерживаемых платформ. В ближайших планах добавлять тестпланы с регресионными тестами на разные части ядра.
Я тут осознал, что этот канал про Software Quality Assurance, а это значит, что зря я ограничиваю тематику постов одним только тестированием ПО. Поэтому теперь буду разбавлять постами про статический и динамический анализ кода, формальную верификацию и т.д.
Для того, чтобы узнать о ближайших конференциях по тестированию есть список на https://testingconferences.org/. Но там нет митапов. Я знаю, что в Москве и Питере более-менее регулярно проходят встречи тестировщиков. Как вы про них узнаёте? Есть где-то расписание?
Инструменты разработки для Rust развиваются с использованием документов RFC (Read For Comments), чтобы перед реализацией участники сообщества могли высказаться и обсудить будущие нововведения. Я заметил RFC для тестовых фреймворков и не упустил возможности предложить использование стандартных форматов вывода.
Группа единомышленников решила составить карту навыков и модель развития тимлидов - https://github.com/tlbootcamp/tlroadmap. Многие из навыков уже описаны, а вот навык "Обеспечение качества продукта" пока остаётся незаполенным. У меня пока нет времени на это. Может кто-то желает взяться?