Junior1997,

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

love_bachТестирвать интефейсы - оверхед

Серьёзно?




Если мы покрываем тестами класс MySuperService, мы должны убедиться, что метод DoSomething вызовет метод Send у IMailService, и вызовет правильно. Если что-то возвращается из сервиса, то проверить, что данные правильно интерпретированы.

Какой ещё оверхед? Чего вы там городите? )))

fkthatlove_bachТестирвать интефейсы - оверхед

WTF "тестировать интерфейсы"?

Почему нет-то? Особенно с учётом, что у интерфейсов теперь появились дефолтные методы

fkthathVosttПочему нет-то? Особенно с учётом, что у интерфейсов теперь появились дефолтные методы

По мне так от дефолтных методов каким-то злом попахивает.

да, теперь уже и не скажешь, что интерфейсы отличаются от классов наличием реализации у последних )))

love_bachну, это конечно не называется "тестирование интерфейсов"

интерфейсы это что?
это контракт.

тестирование правильного использования контракта в данном случае чем является?
тестирование интерфейса.

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

но. это ещё не всё.

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

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

и это ещё не всё.

сам интерфейс может быть протестирован как набор кейсов, покрывая все инварианты использования конкретного экземпляра интерфейса, независимых от реализации. это и есть тестирование интерфейса.

ЕвгенийВhVosttк примеру, у вас на проекте может быть принято соглашение, например, для каждого сервисного интерфейса должен быть указан в атрибутах тип реализации, для автоматической регистрации зависимости.

Это что же получается то? Модули верхнего уровня зависят от модулей нижнего уровня, абстракции зависят от деталей. Вах-вах!

в каком месте-то? )

fkthatтестирование правильного использования контракта это тестирование потребителя этого контракта.

код теста имитирует потребителя.

fkthatЧеловеческим языком это можно было бы озвучить так: "При условии, что реализация "IReader.ReadData" вернет данные "testData", метод "ObjectUnderTheTest.ReadAndWrite" должен вызвать метод "IWriter.WriteData" с этими данными." Где тут имитация? Тестируется именно concrete method ReadAndWrite класса ObjectUnderTheTest.

контракты тоже можно тестировать :)
на предмет полноты и достижимости.
плюс, гарантия, что контракт не изменится, а если изменится, то как это повлияет на сценарии использования.

например:





тест





интересует декларативное выполнение контракта, а не реализация.
виден сценарий использования контракта.

:)

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 там где это нельзя сделать. "Тестировать контракт" тут как-то просто не очень удачное выражение, лучше "тестировать соблюдение контракта его клиентами".

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