Сначала написано, что есть 2 оценки: на глазок (считай, неверная) и на основе исторического опыта (эмпирическая).
Затем утверждается, что брать эмпирическую нельзя, т.к.ситуация будет новая.
А потом много-много буков объяснений о том, как много проблем в банке и что минимальная оценка все равно превратиться в эмперичекую – и в итоге добавление банера все равно займет 2 недели :)
Как написали выше, над теорией оценки нужно еще поработать. Но как статья для понимания масштаба катастрофы в Альфе, очень даже здорово. Поэтому лайк ^.^
Посмотрите, как работает реактивный двигатель. Его основа - закон сохранения импульса. Реактивный двигатель работает в космосе. Только взрывается там обычное топливо, а не ядерное. С ядерным топливом принцип аналогичный. Сколько вещества помноженного на скорость после взрыва улетело в одну сторону, столько же вещества помноженного на скорость разгонится в другую сторону. В одну сторону отлетают продукты взрыва, в другую – корабль.
Спасибо за содержательную дискуссию. Еще один плюсик к моей теории. Действительно же. Независимый UI не есть переиспользуемый. А так хочется переиспользуемого UI и мне тоже! :)
А! и дайте знать в личку, что получится, пожалуйста. Мне это важно.
Рад, что тема зашла. Будет хоть с кем обсудить. А то я пока кому ни скажу, меня не очень понимают. Скорее потому, что сам еще, как следует, сформулировать не могу.
Кстати, хорошая метафора. Адаптер – он и есть адаптер. С одной стороны "мама", с другой - "папа". Их мы все видим в хозяйстве и как использовать понимаем. А Медиатор - это шнур с двумя "папами". Такое у нас встречается все же реже. Но оно в обиходе требует меньше проблем. Представьте, если бы вы соединяли монитор с компом через адаптер, а не одним шнуром, да? :) Забрал метафору себе в коллекцию. Буду объяснять теперь на примере.
Что касается вопроса, нужно ли так делать всегда, то есть ощущение, что нужно. Apple пишет так:
View objects and model objects should be the most reusable objects in an application. View objects represent the "look and feel" of an operating system and the applications that system supports; consistency in appearance and behavior is essential, and that requires highly reusable objects. Model objects by definition encapsulate the data associated with a problem domain and perform operations on that data. Design-wise, it's best to keep model and view objects separate from each other, because that enhances their reusability.
A goal of a well-designed MVC application should be to use as many objects as possible that are (theoretically, at least) reusable. In particular, view objects and model objects should be highly reusable. (The ready-made mediating controller objects, of course, are reusable.) Application-specific behavior is frequently concentrated as much as possible in controller objects.
Говоря, другими словами. Если в вашем приложении переиспользуется, как можно больше всего, то вы меньшими усилиями получаете больший результат.
Если вы переиспользуете вьюхи, то результат вы получите быстрее, чем если не переиспользуете их и работаете с адаптерами.
Это цель MVC. И MVP, я полагаю, тоже. А какая цель у clean?
3. Independent of UI. The UI can change easily, without changing the rest of the system. A Web UI could be replaced with a console UI, for example, without changing the business rules.
Вроде та же. Тоже сделать UI переиспользуемым. Но делает ли Clean переиспользуемым UI? Мой пример про сервер или дизайн показывают, что вряд ли. Я вынужден дорабатывать UI, чтобы он подключился к имеющемуся у меня промежуточному слою. А на кой черт тогда этот промежуточный слой, если он все равно заставляет меня дорабатывать одну из точек взаимодействия с внешним миром? А вот если промежуточный слой сделать по шаблону "Медиатор", то я его создаю сразу под обе стороны, которые я не контролирую, но зато обе эти стороны я использую, как есть. Взял код домена на КММ и впихнул его в веб :)
При этом, получается, что все мое приложение, которое я пишу – это как раз медиатор. Все остальное я не трогаю. Причем, этот медиатор свой на иос, на андроид, и на вебе. А все остальное – переиспользуется.
Кажется, таким и должно быть программирование? Все специфичное для конкретного приложения в самом верху, все остальное – внизу и переиспользуется или взаимозаменяется? У Мартина Фаулера это называется app specific logic.
A screen and components with all application specific behavior extracted into a controller so that the widgets have their state controlled entirely by controller.
А цитату Элла по этому поводу я привел выше в последнем предложении ^.^
Рискну крамольную вещь сказать. Роберт Мартин слегка ошибся со своим средним слоем. Он должен быть верхним. И вот в такой постановке архитектуры, все работает, как часы. :)
Да, Вы правы. Я понял свою ошибку по отношению к чистой архитектуре. Я перевернул зависимости с одной из сторон от среднего слоя. В чистой архитектуре они не перевернуты, все направлены в одну сторону.
Но разрешите все же донести свою мысль. И причину ошибки.
Смотрите, в чистой архитектуре средний слой – это адаптер. Его главная цель, соединить между собой 2 других слоя, которые должны быть независимы и переиспользуемы (вью переиспользуется между приложениями, а доменный слой даже между платформами). Но у этого шаблона проектирования есть небольшой недостаток, он делает зависимым то, что снаружи (сверху) от того, что внутри. Это приводит к проблемам переиспользования: доменную модель мы можем переиспользовать даже между платформами, а вот вью между приложениями уже не можем, т.к. даже имеющиеся вьюшки мы должны адаптировать под протоколы более низких слоев. В итоге, становится тяжело взять, например, текстфилд и перенести его в другое приложение, потому что для него все равно приходится писать адаптер.
Как это должно исправляться? Есть еще один шаблон. Он следует той же цели, но с одним существенным плюсом: слабая связность и отсутствие явных связей соединяемых объектов друг на друга. В таком случае мы не должны менять вью и переиспользовать ее становится гораздо проще. Вспомните типичную мобильную разработку (хоть на иос, хоть на андроид): Вы всегда вынуждены создавать экран... Вы его не можете переиспользовать без дополнительных танцев с бубном в случае с адаптером. А в случае с медиатором можете. И вот медиатор нас возвращает к MVx, в котором средний слой выше!, чем два соседних.
Опять же, если рассматривать
Мне настолько уже удобно использовать медиатор, что я и в чистую архитектуру его засунул. Хотя его там нет. А зря. Мне кажется, что если заменить адаптер в среднем слое clean на медиатор, то всем сразу заживется на порядок проще. И помирит, кстати, MVx, clean и кажется, все другие архитектуры :)
В общем, мне кажется, что медиатор предпочтительнее, чем адаптер во всех случаях. Но доказательств этого тезиса у меня пока нет. Но я Вас приглашаю найти его подтверждения или опровержения, как Вы это сделали с моим тезисом выше.
И да, возвращаясь к исходному моему утверждению про мэпперы, вынужден признать, что они все же находятся в среднем слое, а не в юзкейсе. И да, вполне может быть, что юзкейсов нет, а Entity есть.
Все верно пишите в части того, что слои можно объединять и декомпозировать по необходимости.
Но вот то, как это делают – обычно неверно. Глядите, в чистой архитектуре общение с сервером или базой данных (БД) – это слой View. Внезапно. Он синенький. Это интерфейс общения с внешней системой. Это значит, что общение с сервером или БД должно зависеть от того, что ниже. А ниже у вас юз кейсы. А как делают обычно? Зависимость следующая V -> x -> M. А должно быть V -> x <- M. Видите? Зависимости обратные. Именно поэтому MVP (на андроид) и MVC (на iOS) рисуют с презентером (контроллером) вверху, а вью и моделью внизу. Картинка 7.2 отсюда.
Если это понять, то все встает на свои места. MVx – это не какие-то там "архитектурные паттерны презентационного слоя", это полноценная клин архитектура, в которой буковка М - это композиция Controller и Web (для случая работы с сервером) или Gateway и DB (при работе с локальным хранилищем). Термины из этой картинки. Да, контроллер и презентер тут вступают в конфликт терминологии с паттернами MVx. Но если различать их значения, то проблем восприятия не будет. Мне понравились картиночки вот отсюда. (Там, где написано про слои и линейность.)
Теперь про:
Что делать с юзкейсом, содержимое которого — одна строчка? Вызов репозитория, и всё. Может, в этом случае вызывать репозиторий напрямую?
По идее интерфейс общения с БД и сервером (View к внешним системам) у вас должны быть зависимы от внешней системы и независимы от ваших внутренностей (инверсия зависимости – раз. два – вы делаете визуальный интерфейс под удобство пользователя, а интерфейс сетевого слоя – под запросы сервера). Это значит, что эта самая View к внешним системам имеет свой собственный внутренний формат данных, отличный от вашего внутреннего формата приложения. Поэтому, юз кейс как минимум должен содержать преобразование данных от внешнего формата к внутреннему (к доменной области). Именно так. Видите же выше направления зависимостей? Применяем к ним инверсию зависимостей и получаем то, что нарисовано в чистой архитектуре в правом нижнем углу. Поэтому юзкейс не должен быть пустым. Он как минимум содержит преобразования данных от интерфейса внешних систем (сервера и БД), к интерфейсу с пользователем, через промежуточные внутренние Entity используемые в доменной области.
Конкретный пример. Есть такой инструмент, как Swagger - автоматический генератор сетевого слоя по контракту с сервером. Он генерирует запросы/ответы в своем собственном формате, который вообще не обязан совпадать с тем, что вы используете в доменной области или покажете пользователю на экране. Конечно, есть вероятность того, что форматы совпадут. Тогда юзкейс действительно будет просто проектированием данных. Но это скорее исключение, чем правило. Если же это у Вас правило, то скорее всего Вы неправильно определяете направление зависимостей между интерфейсами внешних систем и внутренними юзкейсами (V -> x -> M).
Кратной. Но в абсолютных цифрах-то это сколько? наносекунды? десятки наносекунд? сотни? Джуны это читают и потом на собесах категорично заявляют, что динамическую диспетчеризацию нельзя использовать ни в коем случае, потому что она "медленная" ^.^
Ну, я считаю, что да. Причины описал выше. Нужно стремиться, чтобы в одном конкретном месте у вас падал только 1 тест. Тогда любой человек через 20 лет придет, увидит 1 упавший тест и за 5 минут поймет, где и что он сломал. А если через 20 лет будет падать 100500 тестов, то этот человек просто удалит такие тесты :)
Базовые принципы тем и хороши, что их можно к любой разработке применять. Даже к вебу или серверу ^.^
если данные не пошли, если пошли, то не будет показан
Вот это мне не очень понятно, но вообще вся идея про 200мс кажется неуместной. а что если запрос будет у вас отрабатывать 300мс, все равно будем мерцание? Но ок, давайте рассмотрим и ее.
Все, что вы тут описали можно разбить на кучу разных тестов с 1 лишь проверкой. Разве нет?
проверяем, что запустился таймер. ждать 200мс в тестах - моветон по двум причинам:
нарушаем буковку F - Fast, тест становится медленным
тестировать системное поведение (то, что таймер вызовется, если мы его запустили) - глупо. Это за пределами нашего влияния, поэтому и тестировать это бесполезно.
показ прогресс бара вы проверяете уже в другом тесте и в другой функции.
отмена прогресс бара - еще один тест.
то, что отмена вызовется по в колбеке получения данных - еще один и т.д.
Еще одно золотое правило в написании тестов: "Разделяй и властвуй". Не старайтесь одним тестом покрыть все Ваше приложение.
А зачем Вам проверять порядок вызова методов у моков?
Есть еще одно золотое правило тестирования. Вы не проверяете внутреннюю реализацию Вашего кода, Вы проверяете результат. Тестирование Вы должны проводить "черного ящика", а не "белого".
Это тоже реализация принципа "Изоляции". Ваш тест не должен зависеть от особенностей реализации Вашего кода. Если Вы захотите отрефакторить Ваш код и поменять реализацию, то Вам придется переписывать все Ваши тесты. А этого надо избегать. И - изоляция.
Подумайте тут, а что же конкретно Вы хотите проверить? Что является результатом работы Вашего метода, который вызывает методы моков? И вот уже этот результат и проверяйте.
Еще можно добавить, что нужно избегать сразу нескольких ассертов в одном тесте. Это имеет смысл только, если проверяемые значения однозначно зависят друг от друга. В других же случаях, лучше написать 2 однотипных тестах, в которых вы проверите только 1 значение.
Чем это лучше? Это реализация свойства "Изоляция" в Ваших тестах. Если Вы сломаете логику расчета одного из проверяемых параметров, то в первом случае у Вас упадет сразу несколько тестов, в каждом вы проверяете несколько результирующих значений – как итог, Вам придется долго сидеть и анализировать все, что происходит в проверяющем тесте, чтобы найти, а в чем же конкретно проблема. Во втором же случае, у вас упадет только 1 тест, в котором только 1 проверка, вы тут же поймете, куда конкретно вам надо смотреть.
Принцип "Изоляции" подразумевает, что в случае проблемы в коде, у вас должен упасть ровно 1 тест, четко указывающий на 1 единственное место, где искать проблему.
Подумайте, как поправить Ваш тест, в котором сразу несколько ассертов.
Лучше все же не плодить шаблонный код, а переработать Ваш код так, чтобы избавиться от лишнего и шаблонного. Шаблонное вполне можно оставить в 1 экземпляре. В статье приводятся причины и дается рецепт исправления.
А мне понравилось следующее.
Сначала написано, что есть 2 оценки: на глазок (считай, неверная) и на основе исторического опыта (эмпирическая).
Затем утверждается, что брать эмпирическую нельзя, т.к.ситуация будет новая.
А потом много-много буков объяснений о том, как много проблем в банке и что минимальная оценка все равно превратиться в эмперичекую – и в итоге добавление банера все равно займет 2 недели :)
Как написали выше, над теорией оценки нужно еще поработать. Но как статья для понимания масштаба катастрофы в Альфе, очень даже здорово. Поэтому лайк ^.^
Не хватило понимания, чем ММ лучше, а чем хуже.
Посмотрите, как работает реактивный двигатель. Его основа - закон сохранения импульса. Реактивный двигатель работает в космосе. Только взрывается там обычное топливо, а не ядерное. С ядерным топливом принцип аналогичный. Сколько вещества помноженного на скорость после взрыва улетело в одну сторону, столько же вещества помноженного на скорость разгонится в другую сторону. В одну сторону отлетают продукты взрыва, в другую – корабль.
https://ru.wikipedia.org/wiki/Реактивная_тяга
А закончить надо было таким утверждением:
А теперь серьезно. Где сравнение-то? Какова цель архитектуры? Тема мрака не раскрыта.
Спасибо за содержательную дискуссию. Еще один плюсик к моей теории. Действительно же. Независимый UI не есть переиспользуемый. А так хочется переиспользуемого UI и мне тоже! :)
А! и дайте знать в личку, что получится, пожалуйста. Мне это важно.
Рад, что тема зашла. Будет хоть с кем обсудить. А то я пока кому ни скажу, меня не очень понимают. Скорее потому, что сам еще, как следует, сформулировать не могу.
Кстати, хорошая метафора. Адаптер – он и есть адаптер. С одной стороны "мама", с другой - "папа". Их мы все видим в хозяйстве и как использовать понимаем. А Медиатор - это шнур с двумя "папами". Такое у нас встречается все же реже. Но оно в обиходе требует меньше проблем. Представьте, если бы вы соединяли монитор с компом через адаптер, а не одним шнуром, да? :)
Забрал метафору себе в коллекцию. Буду объяснять теперь на примере.
Что касается вопроса, нужно ли так делать всегда, то есть ощущение, что нужно. Apple пишет так:
Говоря, другими словами. Если в вашем приложении переиспользуется, как можно больше всего, то вы меньшими усилиями получаете больший результат.
Если вы переиспользуете вьюхи, то результат вы получите быстрее, чем если не переиспользуете их и работаете с адаптерами.
Это цель MVC. И MVP, я полагаю, тоже. А какая цель у clean?
Вроде та же. Тоже сделать UI переиспользуемым. Но делает ли Clean переиспользуемым UI? Мой пример про сервер или дизайн показывают, что вряд ли. Я вынужден дорабатывать UI, чтобы он подключился к имеющемуся у меня промежуточному слою. А на кой черт тогда этот промежуточный слой, если он все равно заставляет меня дорабатывать одну из точек взаимодействия с внешним миром? А вот если промежуточный слой сделать по шаблону "Медиатор", то я его создаю сразу под обе стороны, которые я не контролирую, но зато обе эти стороны я использую, как есть. Взял код домена на КММ и впихнул его в веб :)
При этом, получается, что все мое приложение, которое я пишу – это как раз медиатор. Все остальное я не трогаю. Причем, этот медиатор свой на иос, на андроид, и на вебе. А все остальное – переиспользуется.
Кажется, таким и должно быть программирование? Все специфичное для конкретного приложения в самом верху, все остальное – внизу и переиспользуется или взаимозаменяется? У Мартина Фаулера это называется app specific logic.
А цитату Элла по этому поводу я привел выше в последнем предложении ^.^
Рискну крамольную вещь сказать. Роберт Мартин слегка ошибся со своим средним слоем. Он должен быть верхним. И вот в такой постановке архитектуры, все работает, как часы. :)
Да, Вы правы.
Я понял свою ошибку по отношению к чистой архитектуре. Я перевернул зависимости с одной из сторон от среднего слоя. В чистой архитектуре они не перевернуты, все направлены в одну сторону.
Но разрешите все же донести свою мысль. И причину ошибки.
Смотрите, в чистой архитектуре средний слой – это адаптер. Его главная цель, соединить между собой 2 других слоя, которые должны быть независимы и переиспользуемы (вью переиспользуется между приложениями, а доменный слой даже между платформами). Но у этого шаблона проектирования есть небольшой недостаток, он делает зависимым то, что снаружи (сверху) от того, что внутри. Это приводит к проблемам переиспользования: доменную модель мы можем переиспользовать даже между платформами, а вот вью между приложениями уже не можем, т.к. даже имеющиеся вьюшки мы должны адаптировать под протоколы более низких слоев. В итоге, становится тяжело взять, например, текстфилд и перенести его в другое приложение, потому что для него все равно приходится писать адаптер.
Как это должно исправляться? Есть еще один шаблон. Он следует той же цели, но с одним существенным плюсом: слабая связность и отсутствие явных связей соединяемых объектов друг на друга. В таком случае мы не должны менять вью и переиспользовать ее становится гораздо проще. Вспомните типичную мобильную разработку (хоть на иос, хоть на андроид): Вы всегда вынуждены создавать экран... Вы его не можете переиспользовать без дополнительных танцев с бубном в случае с адаптером. А в случае с медиатором можете. И вот медиатор нас возвращает к MVx, в котором средний слой выше!, чем два соседних.
Опять же, если рассматривать
Мне настолько уже удобно использовать медиатор, что я и в чистую архитектуру его засунул. Хотя его там нет. А зря. Мне кажется, что если заменить адаптер в среднем слое clean на медиатор, то всем сразу заживется на порядок проще. И помирит, кстати, MVx, clean и кажется, все другие архитектуры :)
В общем, мне кажется, что медиатор предпочтительнее, чем адаптер во всех случаях. Но доказательств этого тезиса у меня пока нет. Но я Вас приглашаю найти его подтверждения или опровержения, как Вы это сделали с моим тезисом выше.
И да, возвращаясь к исходному моему утверждению про мэпперы, вынужден признать, что они все же находятся в среднем слое, а не в юзкейсе. И да, вполне может быть, что юзкейсов нет, а Entity есть.
Все верно пишите в части того, что слои можно объединять и декомпозировать по необходимости.
Но вот то, как это делают – обычно неверно. Глядите, в чистой архитектуре общение с сервером или базой данных (БД) – это слой View. Внезапно. Он синенький. Это интерфейс общения с внешней системой. Это значит, что общение с сервером или БД должно зависеть от того, что ниже. А ниже у вас юз кейсы. А как делают обычно? Зависимость следующая V -> x -> M. А должно быть V -> x <- M. Видите? Зависимости обратные. Именно поэтому MVP (на андроид) и MVC (на iOS) рисуют с презентером (контроллером) вверху, а вью и моделью внизу. Картинка 7.2 отсюда.
Если это понять, то все встает на свои места. MVx – это не какие-то там "архитектурные паттерны презентационного слоя", это полноценная клин архитектура, в которой буковка М - это композиция Controller и Web (для случая работы с сервером) или Gateway и DB (при работе с локальным хранилищем). Термины из этой картинки. Да, контроллер и презентер тут вступают в конфликт терминологии с паттернами MVx. Но если различать их значения, то проблем восприятия не будет. Мне понравились картиночки вот отсюда. (Там, где написано про слои и линейность.)
Теперь про:
По идее интерфейс общения с БД и сервером (View к внешним системам) у вас должны быть зависимы от внешней системы и независимы от ваших внутренностей (инверсия зависимости – раз. два – вы делаете визуальный интерфейс под удобство пользователя, а интерфейс сетевого слоя – под запросы сервера). Это значит, что эта самая View к внешним системам имеет свой собственный внутренний формат данных, отличный от вашего внутреннего формата приложения. Поэтому, юз кейс как минимум должен содержать преобразование данных от внешнего формата к внутреннему (к доменной области). Именно так. Видите же выше направления зависимостей? Применяем к ним инверсию зависимостей и получаем то, что нарисовано в чистой архитектуре в правом нижнем углу. Поэтому юзкейс не должен быть пустым. Он как минимум содержит преобразования данных от интерфейса внешних систем (сервера и БД), к интерфейсу с пользователем, через промежуточные внутренние Entity используемые в доменной области.
Конкретный пример. Есть такой инструмент, как Swagger - автоматический генератор сетевого слоя по контракту с сервером. Он генерирует запросы/ответы в своем собственном формате, который вообще не обязан совпадать с тем, что вы используете в доменной области или покажете пользователю на экране. Конечно, есть вероятность того, что форматы совпадут. Тогда юзкейс действительно будет просто проектированием данных. Но это скорее исключение, чем правило. Если же это у Вас правило, то скорее всего Вы неправильно определяете направление зависимостей между интерфейсами внешних систем и внутренними юзкейсами (V -> x -> M).
Что думаете?
https://habr.com/ru/post/714830/
Кратной. Но в абсолютных цифрах-то это сколько? наносекунды? десятки наносекунд? сотни? Джуны это читают и потом на собесах категорично заявляют, что динамическую диспетчеризацию нельзя использовать ни в коем случае, потому что она "медленная" ^.^
На самый главный вопрос-то не ответили.
Насколько различается самый медленный тип диспетчеризация от самого быстрого? В каких случаях имеет смысл учитывать скорость?
а где и зачем их используют в Swift? :)
Ну, я считаю, что да. Причины описал выше. Нужно стремиться, чтобы в одном конкретном месте у вас падал только 1 тест. Тогда любой человек через 20 лет придет, увидит 1 упавший тест и за 5 минут поймет, где и что он сломал. А если через 20 лет будет падать 100500 тестов, то этот человек просто удалит такие тесты :)
Базовые принципы тем и хороши, что их можно к любой разработке применять. Даже к вебу или серверу ^.^
Вот это мне не очень понятно, но вообще вся идея про 200мс кажется неуместной. а что если запрос будет у вас отрабатывать 300мс, все равно будем мерцание? Но ок, давайте рассмотрим и ее.
Все, что вы тут описали можно разбить на кучу разных тестов с 1 лишь проверкой. Разве нет?
проверяем, что запустился таймер. ждать 200мс в тестах - моветон по двум причинам:
нарушаем буковку F - Fast, тест становится медленным
тестировать системное поведение (то, что таймер вызовется, если мы его запустили) - глупо. Это за пределами нашего влияния, поэтому и тестировать это бесполезно.
показ прогресс бара вы проверяете уже в другом тесте и в другой функции.
отмена прогресс бара - еще один тест.
то, что отмена вызовется по в колбеке получения данных - еще один и т.д.
Еще одно золотое правило в написании тестов: "Разделяй и властвуй". Не старайтесь одним тестом покрыть все Ваше приложение.
А зачем Вам проверять порядок вызова методов у моков?
Есть еще одно золотое правило тестирования. Вы не проверяете внутреннюю реализацию Вашего кода, Вы проверяете результат. Тестирование Вы должны проводить "черного ящика", а не "белого".
Это тоже реализация принципа "Изоляции". Ваш тест не должен зависеть от особенностей реализации Вашего кода. Если Вы захотите отрефакторить Ваш код и поменять реализацию, то Вам придется переписывать все Ваши тесты. А этого надо избегать. И - изоляция.
Подумайте тут, а что же конкретно Вы хотите проверить? Что является результатом работы Вашего метода, который вызывает методы моков? И вот уже этот результат и проверяйте.
Пример покажете? Можно будет подумать вместе.
Еще можно добавить, что нужно избегать сразу нескольких ассертов в одном тесте. Это имеет смысл только, если проверяемые значения однозначно зависят друг от друга. В других же случаях, лучше написать 2 однотипных тестах, в которых вы проверите только 1 значение.
Чем это лучше? Это реализация свойства "Изоляция" в Ваших тестах. Если Вы сломаете логику расчета одного из проверяемых параметров, то в первом случае у Вас упадет сразу несколько тестов, в каждом вы проверяете несколько результирующих значений – как итог, Вам придется долго сидеть и анализировать все, что происходит в проверяющем тесте, чтобы найти, а в чем же конкретно проблема. Во втором же случае, у вас упадет только 1 тест, в котором только 1 проверка, вы тут же поймете, куда конкретно вам надо смотреть.
Принцип "Изоляции" подразумевает, что в случае проблемы в коде, у вас должен упасть ровно 1 тест, четко указывающий на 1 единственное место, где искать проблему.
Подумайте, как поправить Ваш тест, в котором сразу несколько ассертов.
Дедушка Мартин это назвал FIRST. Легко запомнить. Как SOLID для приложений.
Лучше все же не плодить шаблонный код, а переработать Ваш код так, чтобы избавиться от лишнего и шаблонного. Шаблонное вполне можно оставить в 1 экземпляре. В статье приводятся причины и дается рецепт исправления.
Даже, наварное, надо как-то так:
1. Компонент уровня вью обязан удовлетворять шаблону "Компоновщик".
2. Компонент уровня презентера и выше рекомендовано удовлетворять шаблону "Компоновщик".
Удалено.