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

2020-09-23 15:06:10 Разработчики Allure встроили отправку анонимной статистики в отчёты и не написали об этом ни слова в документации, только краткое описание в одном из файлов репозитория Allure. В статистику попадают такие данные, как используемая версия Allure, тип используемой CI системы, количество тестовых результатов, количество плагинов, название тестового фреймворка и язык программирования, используемый для тестов.К счастью, отправку статистики можно отключить. Если вы не хотите отправлять данные, то есть возможность отключить отправку через переменную окружения:

export ALLURE_NO_ANALYTICS=1

Отправка статистики имела бы смысл, если бы разработчики публиковали её публично (думаю многим было бы интересно посмотреть общие результаты), но это, к сожалению, закрытые данные. Открыть/Комментировать

2020-09-22 13:45:53 Сейчас идёт трансляция Heisenbug Show, где Никита Макаров с Андреем Сатариным, который работает инженером в Amazon, обсуждают тестирование распределённых систем. Вряд ли Андрей расскажет что-то новое в этой области, но если вы до этого не смотрели интервью с ним, то вам может быть интересно.



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

2020-09-22 13:21:45 ​​Прочитал книгу "Software Engineering в Google," в ней очень подробно и c множеством деталей написано про систему сборки, документацию, тикет-систему, версионирование, дизайн документы, ревью кода, рефакторинг, статический анализ, непрерывную интеграцию, юнит-тестирование, компромиссы при проектировании. Прочитав эту книгу, вы будете в большом плюсе перед остальными - в этой книге слишком много собрано правильных вещей, которые возможно только несколько компаний в мире пытаются решить на таком масштабе, а самое главное - эта книга расскажет про практики и про то, что в итоге сработало, что не сработало и как оценивать вещи в разработке в целом. Есть там отдельные главы про обеспечение качества и, как мне показалось, некоторые из них добавили формально. Например есть небольшой раздел про формальную верификацию, где про неё написано общими словами. Вот, дескать, есть такая практика для снижения некоторых типов ошибок и мало написано про используемые в Google инструменты и успешные проекты. Открыть/Комментировать

2020-09-17 10:00:22 ​​Flaky ("моргающие", нестабильные) тесты - это бич любого программного проекта и есть разные способы их выявления. Один из самых популярных это запускать тесты больше одного раз подряд. Если тест хотя бы один раз пройдет успешно, значит это нестабильный тест. У этого способа есть как и плюсы так и минусы. Есть изящное решение, которое предлагают авторы DeFlaker - в случае нестабильного поведения теста покрытие кода проекта будет отличаться, поэтому они предлагают собирать каждый раз информацию о покрытии кода продукта и сравнивать его с зафиксированным ранее результатом. Тестировать проект с включенной инструментацией для сбора информации о покрытии так себе идея. Есть и другие способы для выявления нестабильных тестов, но, к сожалению, серебряной пули в этой области нет.

Причина нестабильных тестов в недетерминированном поведении кода и общие причины недетерминированного поведения известны давно. В результатах исследований из академических статей и в известной статье Фаулера одни и те же причины перечислены: Lack of Isolation, Asynchronous Behavior, Remote Services, Time, Resource Leaks. Цитата из статьи "What is the Vocabulary of Flaky Tests?": "The top three categories of flaky tests are Async Wait, Concurrency, and Test Order Dependency. Most of flaky tests (78%) are flaky the first time they are written. Average number of days it takes to fix a test was 388.". Почти для всех общих причин можно привести примеры кода, которые тоже будут общими для разных проектов. А раз так, то можно сделать статический анализатор, который будет выявлять куски кода, потенциально приводящие к недетерминированному поведению.

Ранее писал про статический анализ на коленке и рассказал про Coccinelle. Недостаток этого инструмента в том, что он ограничен только поддержкой языка Си, а я пользуюсь не только им и хочется что-то подобное и для других языков программирования. И такой инструмент есть, это semgrep, который изначально сделали в Facebook, потом забросили и какие-то ребята с одним из бывших разработчиков этого инструмента сделали стартап.

В чём прелесть semgrep? Если вы когда-нибудь хотите сделать статическую проверку в коде, то вы будете использовать grep, который не учитывает семантику кода, или специфичный для вашего языка статический анализатор (например flake8 для Питона) и разбираться как работать с AST, чтобы добавить вашу собственную проверку. Если нужно будет добавить похожую проверку для кода на другом языке, например JS, то всю работу вы будете делать заново, добавляя проверку в ESLint. С semgrep вы на DSL описываете паттерн кода, который вы хотите найти и всё! Остальную работу (парсинг кода в AST и поиск кода по вашему паттерну) делает semgrep. Причем он поддерживает самые популярные в коммерческой разработке ПО языки: Go, Java, JavaScript, Python, Ruby, C.

Вообщем я сделал несколько правил для semgrep и буду добавлять ещё по мере необходимости. Буду вам благодарен, если вы запустите semgrep с моими правилами на коде своего проекта и расскажите о результатах.

https://github.com/ligurio/semgrep-rules Открыть/Комментировать