@vr1/be-driven-syntax-sugar

Синтаксический сахар, для того чтобы тесты, такие как pw или jest, писать в виде bdd тестов.

Мотивация

Цель появления этой библиотеки - получить преимущества подхода к тестированию через given-when-then, известного как Behavior Testing или Behavior Driven Development, и при этом не получить недостатков "главного" фреймворка этот подход воплощающего - cucumber.

Подход BDD предполагает следующие преимущества:

1. Описание тестов бизнес-языком (как противопоставление техническому языку)
2. Разбитие тестов на отчётливые шаги/степы даёт переиспользование и пермутабельность. Пермутабельность это возможность составить новые тесты, например edge-кейсы, с использованием уже существующих степов без написания новых или с минимальным их написанием.
3. Сам подход разбития на степы даёт возможность добавления вариативности в тесты. Это преимущество не воплощено в cucumber/gherkin, но теоретически всегда было возможно. Но воплощено здесь.

Недостатки фреймворка cucumber, в частности языка gherkin: для описания последовательности тестов используется текстовый язык, и для привязки степов в коде к мнемоникам в тесте используются регулярные выражения. Изначально задумывалось, что язык gherkin позволит писать тесты не-программистам, т.е. бизнес-аналитикам, продукт-овнерам, тестировщикам-мануальщикам. Однако, по факту, во всех проэктах, где я работал, не-программисты всегда сопротивляются этому и активно отказываются в этом участвовать, а то и вовсе саботируют эту возможность. Отсюда получается, что gherkin не дал того для чего был задуман, но привнёс сложности, которые не нужны тем людям, кто реально пишет тесты - программистам и тестировщикам-автоматизаторам. Сложности заключаются в следующем:

1. Для матчинга используются регулярные выражения, которые добавляют некоторую когнитивную сложность сами по себе.
2. Неочевидные ошибки, когда две регулярки могут поматчиться на мнемонику или наоборот ни одна, и тест, который должен бы работать - не работает.
3. Все степы становятся "глобальными", что накладывает на них дополнительные требования, их нужно писать "более универсальными", чтобы они работали в максимально возможном количестве комбинаций
4. Глобальность также добавляет проблему пересечения контекстов, где степы, которые имеют похожее "звучание", и можно по ошибке вставить мнемонику принадлежащую "чужому контексту", и также получить нерабочий тест
5. Поскольку язык текстовый, то сильно ограничена возможность передачи параметров, они могут представлять из себя только строку или число. Есть также механизм передачи таблиц (состоящих также из строк и чисел), но он просто ужасен, пользоваться им неудобно.

От этих недостатков свободна библиотека @vr1/be-driven а также её аналог - адаптер к существующим тест-раннерам - @vr1/be-driven-syntax-sugar

1. Степы это обычные TS функции и для их использования нужно явно заимпортировать нужный степ и вставить в функцию given, when или then.
2. Уровень "глобальности" может определить сам разработчик, можно сделать как глобальные шаги, так и локальные, которые можно использовать только в контексте тестов определённой фичи или группы фич
3. Параметром могут быть не только строки и числа, но и enum, массивы, POJO объекты, и вообще любые типы данных доступные в TS. Тут хочется порекомендовать разработчику не злоупотреблять этой возможностью, и не использовать в качестве параметров степов такие сущности, как например стримы или сервисы, т.е. не скатываться на обратную сторону этой монеты.

todo дописать ридми

ограничение

Тест может быть только асинхронным, хотя шаги могут быть и синхронными.

пример теста

test('my test', async () => {
    await scenario((name, type, func) => test.step(`${type} ${name}`, func))
      .given(givenStep)
      .when(whenStep)
      .then(thenStep);
});