Сфокусированность теста обратно пропорциональна его полезности. Т.е., набор несфокусированных тестов всегда строго лучше, чем эквивалентный набор сфокусированных, т.к. отловит строго большее количество ошибок.
Если определять полезность как количество ошибок, которое может поймать тест, тогда то, что сфокусированность обратна этой величине вытекает из определения.
Я привык считать полезностью теста то, насколько он облегчает разработку. По опыту, тест, который падает на каждый чих не очень полезен, т.к. при его падении непонятно что конкретно сломалось.
Философский вопрос. Я бы сказал, что не прекрасно, т.к. даже в интеграционных тестах нужно стремиться к сфокусированности. Если мы от неё отказываемся, то для этого должна быть веская причина, например низкая скорость выполнения теста. В нашем случае тест хоть и не быстрый, но еще не настолько медленный, чтобы мы не могли написать отдельный тест на каждый из кейсов.
Хорошее замечание. Я сам об этом думал, когда делал пример. Он, действительно, получился не очень удачным, но проверять промежуточный результат я бы не стал, т.к. в этом случае нарушится требование сфокусированности теста — у теста появится вторая причина для падения.
Здесь два dispatch подряд можно интерпретировать как то, что мы хотим проверить, что событие click() никак не изменит то, что в итоге в стейт будет просуното то, что вернётся в последнем событии.
Можно ли накосячить при написании DSL? Да, разумеется.
Можно ли накосячить в сложном сетапе юнит-теста? Да, разумеется.
Разница только в том, что в первом случае косяк придется править только в одном месте, а во втором во всех тестах, использующих этот сетап.
По поводу того, что проверяется только вызов метода: это называется "тест на поведение". О том, что следует писать тесты на состояние, а не на поведение я упоминал в статье.
Ну и в целом, если юнит-тесты проходят, это еще далеко не значит, что у вас всё хорошо. Зато если они падают, значит всё точно плохо :)
То, что удобно использовать при разработке бизнес-логики не обязано быть удобным для тестов и DSL как раз помогает сгладить это несоответствие.
Мы стараемся писать комментарии только в самых крайних случаях. А использовать BDD фреймворки в юнит-тестах мне представляется оверхедом посильнее DSL.
Дебаг любого теста со сложным сетапом не самое приятное занятие. Согласен, DSL явно не поможет его упростить, но и не сильно усложнит.
Я считаю, что самых лучших результатов можно добиться, если использовать AutoFixture вместе с кастомным DSL, а не вместо него, но это за скоупом статьи.
Я думаю, тут нет однозначного ответа использовать или нет. Я считаю, что использование билдеров несёт больше плюсов чем минусов. Более того, с минусами сам ни разу не сталкивался. Возможно у вас другой опыт и это интересно.
Расскажите плз, как вам мешала необходимость изучения структуры билдеров?
Кроме парной работы, есть еще одна причина: мы постепенно переводим наше решение на .net core и переходим на маки. Студия, к сожалению, работать на маках пока не умеет(
Если определять полезность как количество ошибок, которое может поймать тест, тогда то, что сфокусированность обратна этой величине вытекает из определения.
Я привык считать полезностью теста то, насколько он облегчает разработку. По опыту, тест, который падает на каждый чих не очень полезен, т.к. при его падении непонятно что конкретно сломалось.
Здесь два dispatch подряд можно интерпретировать как то, что мы хотим проверить, что событие click() никак не изменит то, что в итоге в стейт будет просуното то, что вернётся в последнем событии.
Не понял, почему не помогает? Ордер — это, кстати, не мок, а тестовые данные.
Конкретно здесь Testable нужен только для того, чтобы завернуть в себя ассёрты на моках и создание самих моков. Protected методов тут нет.
Но, например для рефакторинга легаси можно его использовать и для вызова protected. Пользы будет больше чем зла.
Можно ли накосячить при написании DSL? Да, разумеется.
Можно ли накосячить в сложном сетапе юнит-теста? Да, разумеется.
Разница только в том, что в первом случае косяк придется править только в одном месте, а во втором во всех тестах, использующих этот сетап.
По поводу того, что проверяется только вызов метода: это называется "тест на поведение". О том, что следует писать тесты на состояние, а не на поведение я упоминал в статье.
Ну и в целом, если юнит-тесты проходят, это еще далеко не значит, что у вас всё хорошо. Зато если они падают, значит всё точно плохо :)
Я считаю, что самых лучших результатов можно добиться, если использовать AutoFixture вместе с кастомным DSL, а не вместо него, но это за скоупом статьи.
Расскажите плз, как вам мешала необходимость изучения структуры билдеров?
Подход интересный, но константы всё-равно нужны. Экшены же как-то надо диспэтчить.
Очень напоминает книгу "Проект феникс" про дев опс.
Статья хорошая. Как бывшему одинэснику было интересно узнать об упущенных возможностях)