Комментарии 7
Поздравляю, вы изобрели property-based testing (QuickCheck был пионером, потом это повторили во всех более-менее широко используемых языках).
Осталось прикрутить шринкинг, и можно будет написать заметку про сравнение вашей библиотеки с десятком существующих.
Лови тролля! А если серьезно, то за поздравления спасибо, но мне, к сожалению Вас, в ответ, поздравить не с чем: Вы не поленились написать едкий комментарий, но поленились разобраться чем mock'ирование обектов в целях тестирования отличается от функционального PB-тестирования; forger не имеет никакого отношения к PBT (подразумевающего автоматические проверки предикатов), а направлен совершенно в другую сторону - создание объектов по контракту.
P.S. Но за комментарий спасибо, учту, что стоит подсвечивать более явно.
направлен совершенно в другую сторону — создание объектов по контракту
А в PBT объекты создаются как-то иначе? Автоматические проверки предикатов — это просто следующий естественный шаг, без которого генерация тестовых данных особого смысла не имеет.
mock'ирование обектов в целях тестирования
В вашем коде никаких моков нет. Мок — это про контракты, а не про данные.
Во-первых, давайте спустимся с философских небес на землю и приведем пример создания объекта в рамках typescript-приложения. Далеко ходить не будем и возьмем мой же пример:
interface User {
id: number;
name: string;
isActive: boolean;
}
const user = Forger.create<User>();Можно ли пример того, как тот же fast-check из "десятка существующих" создаст поддельный объект в соответствии с описанием класса/интерфейса? Получится ли у нас это сделать в одну строчку, как в моем примере, или необходимо полностью описать модель объекта отдельным, по сути, классом, с параметризированием каждого поля?
В таком случае, я скорее переизобрел (хотя вообще не считаю, что изобрёл что-то) AutoFixture из C# под typescript, или эта библиотека с Вашей точки зрения тоже никчемная поделка из миллиона?
Идея же о том, что Mock - это исключительно про поведение, а не про данные... Ну ок, как вы охарактеризуете тот же AutoFixture? Мы подделываем именно данные согласно интерфейсу (читай контракту), это не подделка? Как это называется в Вашем словаре?
никчемная поделка из миллиона?
Я нигде ничего не говорил в таком пренебрежительном тоне. Не имеет никакого смысла со мной воевать, я всегда желаю всяческого добра и успехов всем, кто делает и выкладывает в ОСС что-то новое.
Получится ли у нас это сделать в одну строчку, как в моем примере […]
Не знаю. У меня нет опыта работы с PBT конкретно в JS/TS — зато огромный опыт и коммиты в соответствующие библиотеки для erlang/elixir/ruby/haskell в течение более десяти лет. Так вот, согласно моему опыту, простое создание объекта по типам хорошо отработает только в синтетическом примере. В реальной жизни вы упретесь в необходимость параметризации генерации (даты, урлы, да даже простые числа и строки в большинстве случаев). Генерация только по типу сломает вам бизнес-логику примерно в 99% случаев.
Аналоги AutoFixture есть примерно во всех языках, и они совершенно бесполезны по указанным выше причинам. Да, какое-то количество бесполезных юнит-тестов для демонстрации покрытия они закроют, но практическая польза таких тестов — стремится к нулю. Проверять имеет смысл не success path, а ровно наоборот — corner cases.
Джон Хьюз, автор квикчека, не просто ведь наобум придумал PBT. Ваш генератор проверит пустую строку в name? А если да, то завернет ли пустой name вкупе с isActive: true? Без всего этого — генерация довольно бессмысленна.
Я всего лишь указал вам направление, куда имеет смысл развиваться, чтобы библиотекой можно было пользоваться в реальных проектах. А вы зачем-то на меня окрысились. Меньше всего я хотел что-то обесценивать, или глумиться, поверьте.
А вот теперь мы переходим к реальному конфликту подходов, без подколов "кто, что изобрел") И я, к сожалению, не могу согласиться с Вашим подходом в контексте обсуждения.
По факту, я вижу у Вас оценку библиотеки, направленной на unit-тестирование, через призму PBT. С "высоты" своего десятилетнего опыта, могу заметить, что, в рамках unit-тестов, мне прям очень важно быстрое создание рандомных объектов, которые я могу тюнить под конкретный тест. Вы считаете, что такой подход - not true? Может быть, но библиотека в том не виновата, она вообще не про PBT, и не способна следовать за вашими суждениями.
Mock — это исключительно про поведение, а не про данные...
Моки нужны для проверки контрактов, типа мокнули что-то и удостоверились, что данная функция/метод вызывается нужное количество раз с нужными параметрами. Про какой контракт может идти речь, если данные генерируются случайным образом? Типы компилятор сам проверит.
Вот очень внятный текст, который полностью отражает моё понимание смысла моков. Он про эликсир, но это неважно.
Как быстро создавать тестовые данные без лишней рутины: библиотека @artstesh/forger