Протестировал

2022-08-26 11:46:10 Результаты сравнения Address Sanitizer, Memory Sanitizer, Valgrind и Intel Inspector по типу выявляемых ошибок - https://github.com/mediakind-video/memory-sanitizer-benchmark/blob/master/docs/analysis.md Открыть/Комментировать

2022-08-18 19:56:06 Два года назад я делал опрос с вопросом нужен ли материал на тему "Как ускорить регресионное тестирование?" и многие проголосовали с ответом "Да". Мы сейчас в Тарантуле оптимизируем общее время тестирования и все свои мысли на эту тему я изложил в статье в блоге.

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

https://bronevichok.ru/posts/regression.html Открыть/Комментировать

2022-08-18 11:05:44 Внезапно pytest не самый крутой раннер для тестов на Питоне. Результаты бенчмарков показывают, что он ощутимо отстает от других раннеров. В том числе от hammett, который частично совместим с pytest. Источник результатов измерений - https://github.com/boxed/test-benchmarks Открыть/Комментировать

2022-06-10 10:36:53 OpenSSF опубликовал Fuzz Introspector, с помощью которого можно создавать удобные отчёты о фаззинг тестировании. Отчёты для проектов, интегрированных в OSS-Fuzz, - https://oss-fuzz-introspector.storage.googleapis.com/index.html Открыть/Комментировать

2022-06-09 16:09:08 Тоже часто такое замечал: "У опытного тестировщика вырабатывается еще такой навык как буфер памяти. Ну у меня во всяком случае он выработался за годы. Часто бывает выполняя какое-то действие, каскад ввода и вывода происходят практически одновременно. И такой буфер в голове помогает по памяти восстанавливать ход событий за секунды до "аварии", даже если раздел программы тебе незнаком."

via Открыть/Комментировать

2022-06-02 11:14:57 Опубликовали материалы к прошедшей конференции Kernel recipes. Из всех докладов мое внимание привлёк "Test-driven kernel releases" от Guillaume Tucker. Доклад всё на ту же тему, про которую я уже писал - как координировать тестирование Linux ядра в сообществе: кто и какие тесты запускает, как и где публиковать тестовые отчёты, как минимизировать усилия по тестированию ядра. Если RedHat CKI, KernelCI и syzbot я слышал, то про regzbot было интересно узнать. Это такая штука ля отслеживания регрессий при разработке ядра, есть более подробный пост про regzbot. В докладе автор предлагает три RFC: хранение отчётов о результатах тестирования в репозитории с исходным кодом, использование трейлера Test-link для связи с результатами тестов в описании коммитов, хранение тестовых отчётов в Git и привязка их к коммитам. Тезисы доклада и запись.

P.S. Мне кажется идея хранения тестовых отчётов вместе с кодом в Git классная. Всегда можно посмотреть как тот или иной патч был протестирован. Это не сильно нужно когда всё тестирование синхронное с разработкой - получили зеленую галочку в CI и можно мержить, но полезно, когда после мёржа запускаются остальные тесты. Я даже делал поддержку в cgit для тестовых отчётов, но патчи не нашли понимание в глазах ментейнеров cgit :) Открыть/Комментировать

2022-05-12 09:50:40 Контекст: Google запретил российским и белорусским opensource проектам участвовать в Google Summer of Code 2022, как они определяют национальность открытого исходного кода они не пояснили.

Поэтому команда Tarantool открыла набор на студенческую программу для работы над исследовательскими задачами. Старт запланирован на 1 июля. В первую неделю менторы из числа сотрудников Tarantool познакомят участников с проектом и технологиями, а студенты смогут выбрать задачи, с которыми им предстоит работать — средней или повышенной сложности. Полный список задач, отобранных командой Tarantool - https://github.com/tarantool/tarantool/wiki/Tarantool-Summer-of-Code-2022-ideas. Напоминаю, что среди этих задач есть две, непосредственно связанные с тестированием: фаззер для LuaJIT и интеграция Tarantool с SQLancer.

Решать задачи можно в одиночку или в команде. На задачи средней сложности отводится два месяца, на более сложные — четыре. Разобраться с вопросами и трудностями, возникающими в процессе, поможет ментор. После успешного выполнения участники получат вознаграждение: 120 или 240 тысяч рублей, в зависимости от сложности задачи.

Для участия нужно зарегистрироваться, заполнив форму. Список участников будет объявлен в конце июня 2022 года. Открыть/Комментировать

2022-04-28 20:13:49 Есть такой формат тестовых отчётов как Test Anything Protocol (TAP). Он существует примерно с 1988 года (на несколько лет старше JUnit) и широко используется в библиотеках для написания тестов.

TAP version 13
1..5
ok - gh-695: avoid overwriting tuple data necessary for smfree()
ok - gh-1185: no crash in matras_touch
ok - gh-1094: box.snapshot() doesn't abort if out of file descriptors
ok - No crash for second snapshot w/o any changes
ok - Snapshot was recreated

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

Из нового:

- спецификация теперь описывает наличие пробелов до и после директив SKIP, TODO
- новое ключевое слово Pragma, которое позволяет управлять поведением тестовой библиотеки
- наличие строк, которые не соответствую грамматике TAP, делают весь отчёт невалидным. Раньше, насколько помню, это было на усмотрение тестовой библиотеки.
- вложенные тесты
- закомментированные тесты

http://testanything.org/tap-version-14-specification.html Открыть/Комментировать

2022-04-22 10:32:23 До сих пор в фреймворке Jepsen не было поддержки внедрения сбоев на уровне файловой системы, если не считать полумертвой интеграции с CharybdeFS, которую добавил в Jepsen один из пользователей. Во всяком случае Кайл ни в одном из своих отчётов по тестированию не упоминал про использование сбоев на уровне ФС. Вчера Кайл Кингсбери добавил в Jepsen серию изменения c поддержкой lazyfs, которая реализует сбои такого типа. Причем репозиторий lazyfs по ссылке не доступен и Кайл пока ничего об этом рассказывать не хочет: "Calm dowwwwwwn, this is literally only hours old, already addressed in the commit message, and won't make its way into release for some time.". Судя по коду в коммитах Jepsen lazyfs работает как FUSE файловая система и поддерживает управление с помощью FIFO-канала.

https://github.com/jepsen-io/jepsen/commit/effe3356438f2054294bf4b898fcf69777197f3f Открыть/Комментировать

2022-04-22 10:09:01 23 апреля (уже завтра) в Университете Иннополис пройдёт 2-я международная конференция по качеству кода (Conference on Code Quality, ICCQ). Конференция посвящена таким темам как статический анализ, верификация программ, выявление дефектов и поддержка ПО. Трансляция докладов будет доступна бесплатно, для просмотра нужна регистрация (а может и не нужна, трансляция будет на Ютуб канале). Открыть/Комментировать