Flaky ('моргающие', нестабильные) тесты - это бич любого про | Протестировал
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
