Такой вопрос...

Есть метод сервиса Fun1. Внутри он вызывает другие сервисы, для которых создаются moq-объекты. Но так же внутри вызывает и другие методы этого же сервиса.

Вопрос: стоит ли мокать эти методы того же сервиса, чтобы выполнить так сказать чистое тестирование только одного метода?

Т.е. варианты:

1. Мокать только на уровне сервиса. Если метод вызывает другие методы своего сервиса — вызывает в чистом виде и зависим от них.
2. Мокать и сервисы и методы своего же сервиса.

Кто как делает?

Здравствуйте, Shmj, Вы писали:

S>Т.е. варианты:

S>1. Мокать только на уровне сервиса. Если метод вызывает другие методы своего сервиса — вызывает в чистом виде и зависим от них.
S>2. Мокать и сервисы и методы своего же сервиса.

S>Кто как делает?

Обычно 1, но в военное время можно и 2.
Второй пункт кстати не все моки умеют.

Здравствуйте, bnk, Вы писали:

bnk>Второй пункт кстати не все моки умеют.

А что, какие-то умеют? Думал что проще всего создать наследника — оверрайдить все методы, кроме тестируемого. Соотв-но все методы должны быть virtual...

Здравствуйте, Shmj, Вы писали:

S>Здравствуйте, bnk, Вы писали:

bnk>>Второй пункт кстати не все моки умеют.

S>А что, какие-то умеют? Думал что проще всего создать наследника — оверрайдить все методы, кроме тестируемого. Соотв-но все методы должны быть virtual...

Некоторые могут и приватные методы переписывать, и методы "встроенных" объектов, типа DateTime.Now
TypeMock, JustMock.

Здравствуйте, Shmj, Вы писали:

Есть и альтернативные методы. Тестирование должно производиться без mock фреймворков. Вообще. Это ересь не нужная вообще.
Если метод использует DateTime.Now внутри себя — то это скорее всего проеб. Его не мокать нужно, его нужно делать параметром. Ну и т.п.
Т.е. одно дело предоставить стабы по прямым зависимостям и протестировать — другое дело нагородить какой-то код который динамически мокает какую-то хрень. (Стабильности кода таких тестов можно только посочувствовать).
Чем заниматься такой херней, проще будет заняться black-box тестированием. Будет полезнее в разы. Заодно появится понимание, что должна делать система, а не метод.
К сожалению, это не модно. Ведь надо оправдать цену огорода который ничего полезного не делает.

Здравствуйте, Mystic Artifact, Вы писали:

MA> Есть и альтернативные методы. Тестирование должно производиться без mock фреймворков. Вообще. Это ересь не нужная вообще.

А как без моков тестировать взаимодействие с внешними системами?

Здравствуйте, Буравчик, Вы писали:

MA>> Есть и альтернативные методы. Тестирование должно производиться без mock фреймворков. Вообще. Это ересь не нужная вообще.
Б>А как без моков тестировать взаимодействие с внешними системами?
Можно читать до конца? Для того что бы подсунуть фейковую реализацию интерфейса и подать ее в зависимости — фреймворки которые могут патчить на ходу отдельные методы — не нужны.

Здравствуйте, Буравчик, Вы писали:

Б>А как без моков тестировать взаимодействие с внешними системами?
Я могу и иначе выразиться, но это будет очень грубо и не конструктивно.
По сути, для создания правильного теста необходимо определиться с тем, что мы тестируем или что мы хотим протестировать.
Это краеугольный камень, для того, что бы знать как действовать дальше.

Если вас интересует тест в духе — вызывает ли данный метод что-то при таких параметрах и не вызывает ли при других — то это явно глупый подход. Я прошу обратить внимание, что типичное мокание этим и занимается. А еще оно занимается подгонкой реалий под то, что этот тест вообще сможет выполниться.

"Нормальный" путь — это предоставление зависимостей (ага, через конструктор) которые вас интересуют. Зависимости эти могут быть чем угодно, но наверняка их будет немного (в том плане, что появятся типовые стабы). Иногда появляются спец методы только ради теста, они проламывают чаще всего некую защиту (в т.ч. и безопасность).

Суть и идея — чем больше каждый ваш тест сможет использовать реального кода — тем он лучше — ведь, при изменениях — эти тесты смогут что-то показывать полезное (регрессию), даже если они не были на это запланированы.

В случае "мок" по подобию вопроса ТС — это вырождается в то, что бы найти комбинацию вызовов к мок фреймворку, в которых, этот вызов исполнится. Именно эту задачу решают куча людей в реальном мире, но я и говорю — это просто выгодно. Ничего общего с реальностью и работающим кодом это не имеет. Я лично на такое насмотрелся достаточно.

Здравствуйте, Буравчик, Вы писали:

Б>А как без моков тестировать взаимодействие с внешними системами?

Некоторые прямо так и тестируют — создают в системе спец. тестовый аккаунт (если система не предусматривает тестового режима вызова API — есть и такие), закидывают туда мелочь — и прямо делают тестовые операции при каждом прогоне Unit-тестов (вернее они уже не совсем Unit, но да ладно).

Здравствуйте, Shmj, Вы писали:

S>Некоторые прямо так и тестируют — создают в системе спец. тестовый аккаунт (если система не предусматривает тестового режима вызова API — есть и такие), закидывают туда мелочь — и прямо делают тестовые операции.
Это из области "black-box". Я тебе скажу больше — некоторые создают целые тестовые системы со многими аккаунтами. Разумеется это работает со своими системами и требует немалых трудозатрат, т.к. в маломальски не очень сложных реальных системах можно легко получить комбинаторный взрыв (и мозгом охватить сложно).
Тем не менее, хотя бы частичное применение такого рода тестов вскроют те вещи, которые не тестируют подходы со всякого рода "моками".
Выбор правильного способа тестирования — это задача та еще. В основном, ты просто должен получить наибольшее покрытие при наименьших трудозатратах.

Если взять к примеру, что приложение использует EF (или иной провайдер к БД) — то категорически важно, что бы они точно выполнялись, а не спрятались за стабами.

Все делается исходя из задачи. Например, при тестировании браузерного лэйаута берутся и дампы дерева лэйаута и скриншоты того, что оно там нарисовало. Думаю,подход очевиден.