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

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

Так у в упомянутых тут Microsoft Fakes (Pex & Moles) — как раз killer feature — это генерация stub на обычные классы и функции.

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

A>>если это не мок, то чем это лучше мока?

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

конечно если Вы называете свои классы "Something", Вам надо лезть в реализацию каждого класса чтобы понять что это такое, что он делает, какие у него контракты и т.п.
с ISomething конечно это делать сложнее.

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

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

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

N_P>Так у в упомянутых тут Microsoft Fakes (Pex & Moles) — как раз killer feature — это генерация stub на обычные классы и функции.

В BLToolkit эта фича реализована уже 100 лет, только называется по-другому. Особого оргазма ни у кого не вызвала. Поигрались, покрутили, поцокали языками, поняли, что недостатков больше, чем достоинств и забросили.

Но опять же мы не о том. Мне весь этот цирк начинает напоминать эксперимент с обезъянками, которые каждую новую обезъяну, подсаженную к ним в клетку оттаскивают от банана, потому что так принято. Только вы наоборот, поддаскиваете всех к мокам, но точно так же не можете объяснить зачем они нужны, почему от них больше пользы, чем вреда.

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

A>ок, понятно.
A>моки не нужны потому что говноинтерфейсы мешают писать говнокод.

Ну, дружище, ты даёшь. Это уже похоже на откровенный слив. Давай договоримся, ты этого не писал, а я это не читал.

Вместо этого лучше возьмём вот этот проект, в котором порядка 30,000 параметризированных тестов, но нет ни одного мока. И ты мне расскажешь как бы моки помогли этому проекту. Раз уж вы сами не в состоянии продемонстрировать крутизну моков на своих проектах, то попробуйте это сделать на моём.

N_P>как раз killer feature — это генерация stub на обычные классы и функции.
Вы видимо путаете 2 разные фичи тех же Fakes. Shim-ы и собственно Stub-ы.
Для адекватного человека Stub-ов должно хватать за глаза

IT>Вместо этого лучше возьмём вот этот проект, в котором порядка 30,000 параметризированных тестов, но нет ни одного мока. И ты мне расскажешь как бы моки помогли этому проекту. Раз уж вы сами не в состоянии продемонстрировать крутизну моков на своих проектах, то попробуйте это сделать на моём.
Месье просто не вкурсе что такое юнит тесты и чем они отличаются от других типов тестов

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

IT>Вместо этого лучше возьмём вот этот проект, в котором порядка 30,000 параметризированных тестов, но нет ни одного мока.
конкретный проект это замечательно, но где там юнит тесты?
т.е. такие тесты, которые быстро тестируют отдельные unit'ы кода, в полной изоляции от других unit'ов?

IT>Встречный вопрос. А чем мок лучше не мока. Я вот точно могу сказать чем он хуже. А именно необходимостью использования интерфейсов...

Такой необходимости нет.


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

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

Tom>Месье просто не вкурсе что такое юнит тесты и чем они отличаются от других типов тестов

Меня будем обсуждать или проблему? Или тебе тоже слив засчитать?

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

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

Да там всего хватает, смотри внимательнее.

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

A>А вот без мока протестировать такой сценарий было бы куда сложнее.

Разве этот код использует мок?

IT>Разве этот код использует мок?

Да. Первая строчка определяет мок — вызов DateTime.Now перенаправлять на наш делегат. Вторая строчка демонстрирует использование: вызываем DateTime.Now, а он возвращает то что нам нужно (01/01/2000) вместо текущей даты. И это можно сделать (с некоторыми разумными ограничениями) для любого кода, что нашего, что сидящего внутри .NET. Даже для кода в чужой assembly, для которой у нас нет исходников. Причем не требуется переписывать весь мокаемый класс ради одного метода. И никаких интерфейсов. Никакое изменение мокаемого кода вообще не требуется, никаких дополнительных проверок, ifdef или специальных build targets.

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

IT>>Разве этот код использует мок?

A>Да. Первая строчка определяет мок — вызов DateTime.Now перенаправлять на наш делегат.

Шаманите? Ну да, для этого случая имеет смысл. Ещё применения?

A>Причем не требуется переписывать весь мокаемый класс ради одного метода. И никаких интерфейсов. Никакое изменение мокаемого кода вообще не требуется, никаких дополнительных проверок, ifdef или специальных build targets.

Отсутстаие тепизации не напрягает? Переименовали мокаемые классы и все тесты полетели.

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

IT>Но опять же мы не о том. Мне весь этот цирк начинает напоминать эксперимент с обезъянками, которые каждую новую обезъяну, подсаженную к ним в клетку оттаскивают от банана, потому что так принято. Только вы наоборот, поддаскиваете всех к мокам, но точно так же не можете объяснить зачем они нужны, почему от них больше пользы, чем вреда.

Я не знаю — в чем там вред. А вот в чем вред стандартного Unit-test объинтерфейсивания всего — понимаю. А польза ? Я их редко использую, но вот, например, в недавнем проекте, где надо было графическую часть отлаживать — я эмулировал так данные от сервиса. Вместо реального сервиса выдавал себе тестовый набор. Хотя, наверное, действительно mock и shim путаю Главное — работает

IT>Шаманите? Ну да, для этого случая имеет смысл. Ещё применения?

Что значит шаманите? Вместо DateTime.Now может быть любой метод, свойство или конструктор. Мы подменяем функцию нашей реализацией в делегате, да еще и получаем доступ к членам мокаемого класса. Можно мокать код без исходников, с сильной связанностью, без необходимости определять интерфейсы и писать две разных реализации. Можно использовать одни и те же тесты для production code и тестовой модели. Какие еще применения нужны?

IT>Отсутстаие тепизации не напрягает? Переименовали мокаемые классы и все тесты полетели.

Это не так. Рекомендую ознакомиться с матчастью, чтобы вести предметное обсуждение, а не вываливать личную неприязнь к мокам как подходу вообще.

IT>Меня будем обсуждать или проблему? Или тебе тоже слив засчитать?
Так а смысл обсуждать проблему если ты её не понимаешь.
Судя по постам ты не понимаешь что такое юнит тест и чем он отличается от integration или regression тестов.

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

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

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

IT>Да там всего хватает, смотри внимательнее.

просто скажи имя файла.

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

N_P>Я их редко использую, но вот, например, в недавнем проекте, где надо было графическую часть отлаживать — я эмулировал так данные от сервиса. Вместо реального сервиса выдавал себе тестовый набор.

Вот! Ты эмулировал целый сервис для целой графической части. А здесь нам знатоки моков, которые не в состоянии объяснить зачем они нужны, предлагают использовать такие сервисы в каждом элементарном кусочке кода. Т.е. делать так:

void MyVeryPrimitiveMethod()
{
    var value1 = _service1.GetValue1();
    var value2 = _service2.GetValue2();

    var result = value1 * value2;

    _service3.SetResult(result);
}

И это всё вместо:

int MyVeryPrimitiveMethod(int value1, int value2)
{
    return value1 * value2;
}

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

A>Что значит шаманите? Вместо DateTime.Now может быть любой метод, свойство или конструктор. Мы подменяем функцию нашей реализацией в делегате, да еще и получаем доступ к членам мокаемого класса. Можно мокать код без исходников, с сильной связанностью, без необходимости определять интерфейсы и писать две разных реализации. Можно использовать одни и те же тесты для production code и тестовой модели. Какие еще применения нужны?

Ну т.е. шаманите.

IT>>Отсутстаие тепизации не напрягает? Переименовали мокаемые классы и все тесты полетели.
A>Это не так. Рекомендую ознакомиться с матчастью, чтобы вести предметное обсуждение, а не вываливать личную неприязнь к мокам как подходу вообще.

Кстати, я задал попросил привести хотя бы ещё один пример. С этим проблемы как с юзкейсами в AOP?

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

IT>>Меня будем обсуждать или проблему? Или тебе тоже слив засчитать?
Tom>Так а смысл обсуждать проблему если ты её не понимаешь.
Tom>Судя по постам ты не понимаешь что такое юнит тест и чем он отличается от integration или regression тестов.

Том, ты меня не разочаровал. Если ты окончательно съехал на обсуждение моей личности, значит я прав.

Лет 10 назад по форумам шлялись фаны ФП и во всё горло кричали:
— ФП рулез, ООП авно!
Их спрашивали:
— А в чём рулез?
Они отвечали:
— Вы не понимаете! ФП рулез!
У них опять спрашивали:
— Ну не понимаем, объясните.
На что следовал вполне предсказуемый ответ:
— Вы не можете отличить лямбды от замыкания! ФП рулез, ООП авно!

Самое интересное, что после того как ФП стало обыденным делом эти фаны так и не хотят понять (не НЕ МОГУТ, а именно не хотят), что противопоставлять ФП и ООП бессмысленно, т.к. они в умелых руках только дополняют друг друга.

Эта история, конечно, не про тебя. ФП действительно было трудно взять сходу, это не статью в педивикии про моки почитать. Но с тех пор мне стало понятно одно — если человек не может внятно объяснить свою позицию своему коллеге, не в состоянии чётко обозначить как достоинства так и недостатки защищаемого инструмента, отказвается демонстрировать примеры кода, подтверждающие его правоту, но при этом постоянно скатывается на обсуждение личности и в каждом предложении использует что-то вроде "ты не понимаешь", то мы имеем дело с типичным синдромом фанатеющего функциональщика. И это, пожалуй, точно про тебя.