В книжке Art of unit testing, предлагается скрывать детали не относящиеся к конкретному тесту и показывать связь между исходными данными и результатами. В получившемся результате скрыто почти все (из кода теста непонятно, что и сколько должно быть зарезервировано). Фактически и CreateDualOrder и VerifyReserveIngredientsWasCalledWith внутри используют какие-то константы но как они друг с другом связаны, неясно.
Я бы написал так:
var ingridient = CreateIngridient();
var product = CreateProduct().WithIngridient(ingridient, AmountOfIngridientInProduct).Please();
var order = CreateOrder().WithLine(product, AmountOfProductInOrderLine).Please();
var service = CreateService();
service.AcceptOrder(order);
Assert.Equals(AmountOfProductInOrderLine * AmountOfIngridientInProduct, service.GetReservedAmount(ingridient));
AutoFixture не пользовался, интересно, как там с воспроизводимостью падений. Например, в данном случае вполне возможно, что результат будет работать с точностью до округлений (каковые будет проверять другой тест).
Я думаю, это скорее зависит от языка, чем от фреймворка.
В случае С# property и collection initializers устраняют некоторую потребность в строителях, но все равно есть потребность в бизнес-специфичных алгоритмах типа "создай заказ готовый для исполнения" когда можно убрать под капот какие-то детали создания, не важные для конкретного теста.
Например, тут я бы убрал дату внутрь билдера:
var order = Create.Order
.With(Pizza.Pepperoni.CountOf(1).For(500))
.With(Pizza.Margarita.CountOf(1).For(650))
.Please();
var service = Create.PizzeriaService.Please();
service.AcceptOrder(order);
service.VerifyReserveIngredientsWasCalledWith(order);
Но, внезапно выясняется, что property и collection initializers работают только при создании объекта.
Т.е. написать new Order{ Date = Today } можно, а CreateOrder(){Date = Today} нельзя.
Эффект присутствия может помочь — получение информации по многим каналам насколько удобно человеку работать, о чем у него болит голова, насколько удобен UI и так далее.
Но мне было бы интересно, чтобы присутствующие додо-программисты рассказали про это, а не чтобы я теоретизировал.
А если программист работает на металлургическом заводе, ему что нужно поработать сталеваром, не имея ни допусков по ТБ, ни специфических умений?!
С чего вы решили?
Разумеется все зависит от условий. Летом носят майки, зимой носят шубы. Если нельзя без допуска, то нельзя, если допуск можно получить, то можно.
Вы же не пишете этот комментарий в акваланге на основании того, что кто-то другой в каком-то другом месте без него бы не выжил?
Я думаю, тут дело в том, что юристы используют несколько менее формальную логику чем программисты. В случае гипотетического сферического суда в вакууме может выясниться что использование интернет кабеля является частью прочесса пользования сайтом, а вот умышленная модификация адблоком — нет.
Я имел ввиду исходный лайфхак описанный в статье. Очевидно, просмотр при помощи браузера явно подпадает под ToS («cтраниц видеовоспроизведения на самом Веб-сайте»)
Вы обязуетесь не изменять и не модифицировать какую-либо часть Веб-сайта или Службы (включая, но не ограничиваясь этим, Плеер YouTube и связанные с ним технологии); Вы обязуетесь не получать доступа к Контенту с помощью какой-либо технологии или средств, отличных от страниц видеовоспроизведения на самом Веб-сайте, Плеера YouTube или иных подобных средств, которые YouTube может специально предоставить для указанной цели; Вы обязуетесь не совершать (или не пытаться совершать) следующие действия: обходить, отключать или иным образом вмешиваться в любые связанные с безопасностью характеристики (защитные меры ) Веб-сайта или характеристики (защитные меры), которые (I) предотвращают или ограничивают использование или копирование любого Контента, либо (II) налагают ограничения на использование Службы или информации, доступ к которой может быть получен с помощью Службы;
Фиг знает подпадает это лайфхак под это условие или нет.
При запуске, ага. Это инженерный долг — если его берешь, надо учитывать, что отдавать придется с процентами. «Всегда брать», «никогда не брать» — слишком примитивные стратегии.
«без спешки разрабатывается только ПО, которое заведомо никому не нужно.» — тоже слишком примитивно — каждое ПО разрабатывается со спешкой и без спешки в разные моменты времени.
Вопрос не только в том, что должно и что не должно, а в том, как это работает реально на большинстве людей в конкретной культуре. Я наблюдаю что это стимулирует спешку.
Причем, судя по тому, что некоторые призывы оценивать задачи в условных единицах а не во временных мотивируются так же (чтобы не стимулировать спешку), это наблюдаю не только я.
В книжке Art of unit testing, предлагается скрывать детали не относящиеся к конкретному тесту и показывать связь между исходными данными и результатами. В получившемся результате скрыто почти все (из кода теста непонятно, что и сколько должно быть зарезервировано). Фактически и CreateDualOrder и VerifyReserveIngredientsWasCalledWith внутри используют какие-то константы но как они друг с другом связаны, неясно.
Я бы написал так:
AutoFixture не пользовался, интересно, как там с воспроизводимостью падений. Например, в данном случае вполне возможно, что результат будет работать с точностью до округлений (каковые будет проверять другой тест).
Я думаю, это скорее зависит от языка, чем от фреймворка.
В случае С# property и collection initializers устраняют некоторую потребность в строителях, но все равно есть потребность в бизнес-специфичных алгоритмах типа "создай заказ готовый для исполнения" когда можно убрать под капот какие-то детали создания, не важные для конкретного теста.
Например, тут я бы убрал дату внутрь билдера:
Но, внезапно выясняется, что property и collection initializers работают только при создании объекта.
Т.е. написать new Order{ Date = Today } можно, а CreateOrder(){Date = Today} нельзя.
Для записей есть proposal
Можно просто брать и писать, как будто билдеры уже есть, а потом пусть студия создаст недостающие методы.
Но мне было бы интересно, чтобы присутствующие додо-программисты рассказали про это, а не чтобы я теоретизировал.
С чего вы решили?
Разумеется все зависит от условий. Летом носят майки, зимой носят шубы. Если нельзя без допуска, то нельзя, если допуск можно получить, то можно.
Вы же не пишете этот комментарий в акваланге на основании того, что кто-то другой в каком-то другом месте без него бы не выжил?
Фиг знает подпадает это лайфхак под это условие или нет.
«без спешки разрабатывается только ПО, которое заведомо никому не нужно.» — тоже слишком примитивно — каждое ПО разрабатывается со спешкой и без спешки в разные моменты времени.
Причем, судя по тому, что некоторые призывы оценивать задачи в условных единицах а не во временных мотивируются так же (чтобы не стимулировать спешку), это наблюдаю не только я.
Правда, некоторые считают, что обычно это приводит к спешке, которая вредит качеству.
Вопрос, за счет чего она будет в него укладываться...