fkthathVostt




Ну и "Sum" вернет просто "0". В чем тут тест-то? В том что у "ICalc" просто есть метод "Sum" с двумя параметрами, что ли? Так это и так ясно, если код собирается - не адов JS все-таки.

не вернёт он тут 0. и параметров там два, а не один.
собственно в этом и состоит тест.

love_bachместами ты загоняешься:
"например, для каждого сервисного интерфейса должен быть указан в атрибутах тип реализации, для автоматической регистрации зависимости" - хер ты это протестишь, похожий топик а Java есть

что значит хер протестишь? мы давно покрывает тестами на наличие тех или иных атрибутов и правильного их употребления.


love_bach"для каждого сервисного интерфейса должен быть указан в атрибутах тип реализации, для автоматической регистрации зависимости"
тут какой-то проеб в архитектуре

никакого проёба в архитектуре нет. это нормальное решение, не противоречащее ни одному из принципов.


love_bach"единственный способ гарантировать, что никто не забыл указать атрибут, это протестировать все интерфейсы на предмет наличия правильных атрибутов. без всякой реализации"
как, рефлексией?

нет, блин, волшебным заклинанием

fkthatНу, тут он чота вообще прогнал. Интерфейс вообще не должен нихера знать про свои реализации и все, конец сказке.

Откуда взято это утверждения? Вы наверное путаете с принципом инверсии зависимостей.

Модули верхних уровней не должны зависеть от модулей нижних уровней. Оба типа модулей должны зависеть от абстракций.

Наличие атрибута реализации у интерфейса никак не противоречит. В любом случае, вам где-то нужно зарегистрировать реализацию. Знание всё равно будет где-то размещено. Какая разница где? При чём вы можете переопределить реализацию, указанную через атрибут. Всё по феншую.


fkthatКстати, как они с таким соглашением будут выкручиваться, если у них интерфейс и реализация в разных сборках. А если захочется выпилить вообще нах текущюю реализацию и сделать новую, то придется лезть в интерфейс и менять аттрибут.

Без проблем, во-первых такое решение не всегда нужно использовать, с атрибутом. Во-вторых, вы всегда можете переопределить реализацию при регистрации, если вам это нужно. В третьих, это не мешает реализации оставаться инкапсулированой -- т.е. так и должно быть.


fkthatРегистрация "by conventions" это очень даже упортребляемая вещь, но делается она совсем не так, да и вообще все норм. контейнеры её и так из коробки поддерживают, без всяких половых фантазий с аттрибутами.

Конвенции это как раз одно из решений на атрибутах. Т.е. вы себе уже противоречите :)


fkthat


Вообще, на мой вкус и цвет любая сборка с интерфейсами, классами и т.п. должна быть "container-agnostic", т.е. вообще ничего не знать про то, что её будут через IoC дергать, не говоря уже о том, чтобы как-то зависеть от конкретного контейнера.

В условии Where может быть проверка атрибута. Что не меняет никак ни смысла, ни содержания.

fkthat"Посмотри, что за х...ню ты написал" (с) Ты, вроде бы, умный человек, но периодически начинаешь впадать в какую-то ересь. Соблюдение инвариантов и постусловий - это ответственность кнкретной реализации контракта - без неё ты никак это не протестируешь. Можно, в принципе, протестировать, что потребитель сервиса всегда соблюдает предусловия, но это опять-таки будет тест кода потребителя сервиса, а не кода интерфейса.

Если по-вашему, контракт нельзя протестировать без реализации, то пусть так и остаётся для вас.
Я могу протестировать, при необходимости, и понимаю зачем это нужно.
Вы пока нет. :)

fkthatТут, в принципе, уже все это обсосали. Протестировать можно то, что клиент, использующий этот контракт соблюдает правила его использования, например, как самый банальный вариант, не передаёт в его метод null там где это нельзя сделать. "Тестировать контракт" тут как-то просто не очень удачное выражение, лучше "тестировать соблюдение контракта его клиентами".

Можно и так сформулировать, да.