Хотелось бы иметь хороший инструментарий ( Mocking из коробки и пр. ).

Здравствуйте, Аноним, Вы писали:

А>Хотелось бы иметь хороший инструментарий ( Mocking из коробки и пр. ).
nUnit, xUnit

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Хотелось бы иметь хороший инструментарий ( Mocking из коробки и пр. ).
А>nUnit, xUnit

И где же в nUnit моки ?

А>Хотелось бы иметь хороший инструментарий ( Mocking из коробки и пр. ).

Для моков есть Microsoft Fakes.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Аноним, Вы писали:

А>>Здравствуйте, Аноним, Вы писали:

А>>>Хотелось бы иметь хороший инструментарий ( Mocking из коробки и пр. ).
А>>nUnit, xUnit

А>И где же в nUnit моки ?

Я использую nUnit + Rhino Mocks

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

A>Для моков есть Microsoft Fakes.

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

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

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

A>>Для моков есть Microsoft Fakes.

IT>Для моков есть мозги, которые упорно утверждают, что моки не нужны.

Смелое утверждение. А как-то обосновать можно ?

Здравствуйте, Аноним, Вы писали:

А>Хотелось бы иметь хороший инструментарий ( Mocking из коробки и пр. ).

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

Я бы порекомендовал NUnit (MbUnit, xUnit) (в порядке моих предпочтений). NUnit идет первым, поскольку там наиболее навороченная поддержка параетризованных юнит-тестов, что есть очень гуд.

Из фейк фреймворков можно глянуть на Moq, можно на FakeIt; можно и на Microsoft Fakes, но он доступен только с премиальной студии, что может быть слишком сильным ограничением.

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

Здравствуйте, <Аноним>, Вы писали:

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

Без конкретного кода обосновывать что-либо не имеет смысла. Давайте сюда свой проект, мы на него посмотрим и обоснуем.

IT>Без конкретного кода обосновывать что-либо не имеет смысла. Давайте сюда свой проект, мы на него посмотрим и обоснуем.
Microsoft Fakes это по сути не моки, а именно то что рекомендуют лучшие собаководы.
Если кратко то Fakes генерирует в compile time реализации интерфейсов, в который сама реализация тупо перенаправляет вызов в делегат с соответствующей сигнатурой. Таким образом получается супер лёгкий и простой для понимания stub. Никакой runtime магии. По сути это тупой кодогенератор, который пишется на коленке за 2-3 часа. При этом сама концепция таких stub-ов становится супер мощной при применении в проекте SR/DI принципов.

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

Tom>Если кратко то Fakes генерирует в compile time реализации интерфейсов, в который сама реализация тупо перенаправляет вызов в делегат с соответствующей сигнатурой. Таким образом получается супер лёгкий и простой для понимания stub. Никакой runtime магии. По сути это тупой кодогенератор, который пишется на коленке за 2-3 часа. При этом сама концепция таких stub-ов становится супер мощной при применении в проекте SR/DI принципов.

Вообще-то мы сейчас не о том что и как могут фреймворки, а о том зачем это надо.

IT>Вообще-то мы сейчас не о том что и как могут фреймворки, а о том зачем это надо.
И зачем? Подробнее можно, мысль не понял

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

IT>>Вообще-то мы сейчас не о том что и как могут фреймворки, а о том зачем это надо.
Tom>И зачем? Подробнее можно, мысль не понял

Зачем — это как раз мой вопрос.

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

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

IT>>>Вообще-то мы сейчас не о том что и как могут фреймворки, а о том зачем это надо.
Tom>>И зачем? Подробнее можно, мысль не понял

IT>Зачем — это как раз мой вопрос.
зачем что? блин сломалась мыслечиталка

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

IT>>Зачем — это как раз мой вопрос.
Tom>зачем что? блин сломалась мыслечиталка

Не надо читать мысли, почитай лучше ветку.

IT>Не надо читать мысли, почитай лучше ветку.
Зашибись, приятно пообщались...

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

IT>Для моков есть мозги, которые упорно утверждают, что моки не нужны.

ок.
а юнит тесты нужны?

---

чтобы два раза не вставать, еще вопрос:
вот есть метод который вызывает методы интерфейса ISomething.
для теста нужна какая-то реализация ISomething — где мы ее берем?
мы ее пишем руками, мы используем мок, или может бывает что-то еще?
если это не мок, то чем это лучше мока?

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

A>а юнит тесты нужны?

Обычно нужны.

A>вот есть метод который вызывает методы интерфейса ISomething.
A>для теста нужна какая-то реализация ISomething — где мы ее берем?
A>мы ее пишем руками, мы используем мок, или может бывает что-то еще?

Откуда я знаю? Может быть главной ошибкой в таком дизайне вообще является наличие интерфейса ISomething.

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

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

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

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

Уу ну ты даешь, интерфейсы это как раз рулез. Читабельность не снижается ничуть, да и отлаживать не сложно. Зато офигенная гибкость.

Здравствуйте, <Аноним>, Вы писали:

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

А>Уу ну ты даешь, интерфейсы это как раз рулез. Читабельность не снижается ничуть, да и отлаживать не сложно.

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

А>Зато офигенная гибкость.

Гибкость чего? Вот, например, гибкость кода и процесс его изменения под новые требования лучше всего там, где реализация функционала, над которым необходимо поработать, находится в одном месте. Тогда можно всё быстро поменять и не заботится о том, что где-то что-то сломалось в другом месте. А интерфейсы и прочие паттерны вынуждают программиста размазывать алгоритм по всему коду, объединяя в одном месте куски разношёрстного не связанного с друг другом функционала. Это не даёт гибкость, это даёт хрупкость кода.

Здравствуйте, 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 назад по форумам шлялись фаны ФП и во всё горло кричали:
— ФП рулез, ООП авно!
Их спрашивали:
— А в чём рулез?
Они отвечали:
— Вы не понимаете! ФП рулез!
У них опять спрашивали:
— Ну не понимаем, объясните.
На что следовал вполне предсказуемый ответ:
— Вы не можете отличить лямбды от замыкания! ФП рулез, ООП авно!

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

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

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

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

В каталогах Common, Mapping, Metadata, Reflection можно найти всё. Перелапачивать сейчас сотни тестов нет ни времени ни желания. Тем более, что ты всё равно найдёшь лишь то, что нужно тебе, ведь я прав?

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

IT>Лет 10 назад по форумам шлялись фаны ФП и во всё горло кричали:
IT>- ФП рулез, ООП авно!
IT>Их спрашивали:
IT>- А в чём рулез?
IT>Они отвечали:
IT>- Вы не понимаете! ФП рулез!

Ты так и не понял.

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

ST>Я бы порекомендовал NUnit (MbUnit, xUnit) (в порядке моих предпочтений). NUnit идет первым, поскольку там наиболее навороченная поддержка параетризованных юнит-тестов, что есть очень гуд.

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

(псевдокод)

// test case
{
    var test = (string range) =>
        try
        {
            Interval.Parse(range);
            return true;
        }
        catch (FormatException)
        {
            return false;
        };
        
    check(test("(-Inf,+Inf)") == true);
    check(test("[0,1.5)") == true);
    check(test("(0,0)") == false);
    check(test("[0,-1.12)") == false);
    check(test("(Inf,-Inf]") == false);
    check_exception(() => test(null), typeof(ArgumentNullException));
}

при том что с локальными функциями можно поставить точку останова на строчку с нужным тестом?

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

Я не понимаю, что значит "шаманите"? Это стандартные сценарии использования моков. А по вашему — что такое мок и каким должен быть "правильный" мок-фреймворк?

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

Пример чего? Перехвата метода и детура на наш делегат? Или просто сценария, который исключительно трудно протестировать без применения моков?

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

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

Второе.

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

A>при том что с локальными функциями можно поставить точку останова на строчку с нужным тестом?

Я тоже не понял особо зачем параметризованные тесты нужны, ведь набор провалившихся тестов с проблемами в разных частях диапазона — это лучше, чем один провалившийся тест на все диапазоны сразу (или может там на атрибутах построена особая магия, которая выдаёт нарушения диапазона значений сразу по всем атрибутам?).
Приведённый выше пример страдает той же проблемой — провалится один тест, а проблем внутри может быть сразу много. Да и отлаживать тесты — это то ещё кощунство.

--
С Уважением, Andir!

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

A>чем они лучше чем обычная локальная функция?

Тем, что при провале тесты сразу видно какое значение провалилось. Тем, что можно отлаживать тест для конкретного значения, не ожидая пока прокрутятся все предыдущие. Тем, что можно сказать написав 10 тестов со ста значениями, что у нас в программе 1000 тестов.

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

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

A>>чем они лучше чем обычная локальная функция?

IT>Тем, что при провале тесты сразу видно какое значение провалилось.
с локальной функцией тоже. все зависит от фреймворка.
IT>Тем, что можно отлаживать тест для конкретного значения, не ожидая пока прокрутятся все предыдущие.
во первых юнит-тесты должны прокручиваться *мгноменно*.
во вторых, можно закомментировать лишние строчки, или поставить точку останова на 1й, и в отладчике пропустить не нужные тесты (в MSVS — стрелочку перетащить)
IT>Тем, что можно сказать написав 10 тестов со ста значениями, что у нас в программе 1000 тестов.
с локальной функцией тоже.

еще раз, два куска кода:

[TestCase]
public void Test_Interval_Validity()
{
    var test = (string range) =>
        try
        {
            Interval.Parse(range);
            return true;
        }
        catch (FormatException)
        {
            return false;
        };
        
    check(test("(-Inf,+Inf)") == true);
    check(test("[0,1.5)") == true);
    check(test("(0,0)") == false);
    check(test("[0,-1.12)") == false);
    check(test("(Inf,-Inf]") == false);
    check_exception(() => test(null), typeof(ArgumentNullException));
}

[TestCase("(-Inf,+Inf)", Result = true)]
[TestCase("[0,1.5)", Result = true)]
[TestCase("(0,0)", Result = false)]
[TestCase("[0,-1.12)", Result = false)]
[TestCase("(Inf,-Inf]", Result = false)]
[TestCase(null, Result = false, ExpectedException = typeof(ArgumentNullException))]
public bool Test_Interval_Validity(string range)
{
    try
    {
        Interval.Parse(range);
        return true;
    }
    catch (FormatException)
    {
        return false;
    }
}

в чем разница?

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

IT>>Тем, что при провале тесты сразу видно какое значение провалилось.
A>с локальной функцией тоже. все зависит от фреймворка.

А у меня не зависит. Я просто вижу в решарпере и всё.

IT>>Тем, что можно отлаживать тест для конкретного значения, не ожидая пока прокрутятся все предыдущие.
A>во первых юнит-тесты должны прокручиваться *мгноменно*.

Ага, мгновенно в отладчике через все точки останова.

A>во вторых, можно закомментировать лишние строчки, или поставить точку останова на 1й, и в отладчике пропустить не нужные тесты (в MSVS — стрелочку перетащить)

Можно ещё и гланды вырезать через одно место автогеном, но это как-то неудобно.

A>в чем разница?

В том, что я открываю тест и вижу, что у меня сегодня упали тесты Sybase. Блин, да я же опять виртуальную машину забыл запустить!!!

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

A>в чем разница?

Кстати, ещё забыл сказать. Во-первых, я использую атрибут Values, а не TestCase, а он принимает список значений, которые переопределив атрибут можно выбирать из внешнего источника. В результате я могу легко отключать тесты для тех или иных значений.

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

IT>В каталогах Common, Mapping, Metadata, Reflection можно найти всё. Перелапачивать сейчас сотни тестов нет ни времени ни желания. Тем более, что ты всё равно найдёшь лишь то, что нужно тебе, ведь я прав?

да. это точно, там можно найти многое.

больше всего мне понравился конструктор MemberAccessor, https://github.com/linq2db/linq2db/blob/master/Source/Reflection/MemberAccessor.cs
эпичный говнокод. даже с комментариями.

тестирование глобального состояния в DefaultValueTest.cs меня тоже очень порадовало, особенно его откат в каждом методе.

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

A>больше всего мне понравился конструктор MemberAccessor, https://github.com/linq2db/linq2db/blob/master/Source/Reflection/MemberAccessor.cs
A>эпичный говнокод. даже с комментариями.

Потому что большой и всё в одном месте? Так это классно, чувак! Если ты всегода размазываешь свою логику по методам в две строчки, то это у тебя уже даже не говнокод, а жидкий поноскод. Так что учись пока я жив.

A>тестирование глобального состояния в DefaultValueTest.cs меня тоже очень порадовало, особенно его откат в каждом методе.

Да я уже и так всё понял. Твоего кода мы конечно же не увидим с крутыми моками не высосанными из пальца?

Кстати, смотря мой код ты так и не предложил куда там можно затолкать моки. Или по-твоему нужно всё передизайнить, чтобы они туда таки тулились?

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

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

A>>больше всего мне понравился конструктор MemberAccessor, https://github.com/linq2db/linq2db/blob/master/Source/Reflection/MemberAccessor.cs
A>>эпичный говнокод. даже с комментариями.

IT>Потому что большой и всё в одном месте? Так это классно, чувак! Если ты всегода размазываешь свою логику по методам в две строчки, то это у тебя уже даже не говнокод, а жидкий поноскод. Так что учись пока я жив.

дело не в количестве строчек, а в SRP. у метода может быть 100 строчек, но он должен отвечать за одну штуку, а не за "сделать геттер, сделать сеттер, поковырять в носу"
также я заметил что когда смотрищь на гитхабе, то код не влазит по ширине.

A>>тестирование глобального состояния в DefaultValueTest.cs меня тоже очень порадовало, особенно его откат в каждом методе.

IT>Да я уже и так всё понял. Твоего кода мы конечно же не увидим с крутыми моками не высосанными из пальца?

если бы у меня был опенсорс с подходящей архитектурой — показал бы.

вот я написал недавно прогу которая складывает два числа.
в ней 1 юнит, функция add(), и тот ни от чего не зависит.
очевидно что моки для тестирования такой проги не нужны.

IT>Кстати, смотря мой код ты так и не предложил куда там можно затолкать моки. Или по-твоему нужно всё передизайнить, чтобы они туда таки тулились?

из того что я видел, в твоем коде моки не нужны, т.к. у юнитов нет зависимостей.

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

IT>>Потому что большой и всё в одном месте? Так это классно, чувак! Если ты всегода размазываешь свою логику по методам в две строчки, то это у тебя уже даже не говнокод, а жидкий поноскод. Так что учись пока я жив.

A>дело не в количестве строчек, а в SRP. у метода может быть 100 строчек, но он должен отвечать за одну штуку, а не за "сделать геттер, сделать сеттер, поковырять в носу"

Это всё опять догмы, которые при этом всеми трактуются по разному. Я могу сказать, что этот метод делает одну штуку — инициализацию объекта. Инициализация сложная, но разбиение на методы не даст ровным счётом ничего, ни понимабельности (только ухудшит), ни улучшения поддержки (только запутает).

Кстати, на Немерле методы легко пишутся размером в тысячу строк (но там есть локальные функции и грамотный фолдинг) и никого это никак не напрягает.

A>также я заметил что когда смотрищь на гитхабе, то код не влазит по ширине.

У меня дома три монитора один посередине 24-х дюймовый, нафига мне экономить? На гитхабе я код смотрю несколько раз в год, а дома каждый день.

A>в ней 1 юнит, функция add(), и тот ни от чего не зависит.
A>очевидно что моки для тестирования такой проги не нужны.

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

IT>>Кстати, смотря мой код ты так и не предложил куда там можно затолкать моки. Или по-твоему нужно всё передизайнить, чтобы они туда таки тулились?
A>из того что я видел, в твоем коде моки не нужны, т.к. у юнитов нет зависимостей.

Вот, о чём и речь.

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

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

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

IT>Второе.

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

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

A>прочитал этот пост в блоге, и не понял зачем эти атрибуты нужны.
A>чем они лучше чем обычная локальная функция?

A>(псевдокод)
A>

A>// test case
A>{
A>    var test = (string range) =>
A>        try
A>        {
A>            Interval.Parse(range);
A>            return true;
A>        }
A>        catch (FormatException)
A>        {
A>            return false;
A>        };
        
A>    check(test("(-Inf,+Inf)") == true);
A>    check(test("[0,1.5)") == true);
A>    check(test("(0,0)") == false);
A>    check(test("[0,-1.12)") == false);
A>    check(test("(Inf,-Inf]") == false);
A>    check_exception(() => test(null), typeof(ArgumentNullException));
A>}
A>

В данном случае смешиваются тест-кейс с тестовыми данными. При этом, как будет вести себя тест, если вторая строка свалится? Упадет или пойдет дальше? Или этот велосипед накопит все поломанные тесты и сгенерирует AggregateException со всеми поломанными тестами? Будем ли мы видеть в тест-эксплорере один тест или 6?

Параметризованный тест — это способ генерации множества тест-кейсов декларативным способом. При этом каждый тест-кейс показывается отдельно в тест эксплорере, выполняется независимо и падает тоже отдельно. Так, в случае параметризованных тест-кейсов у вас могут упасть все, 3, или 1. При этом все поломанные тесты видны сразу.

При отсутствии параметризованных тестов всегда можно их сэмулировать написав подобный велосипед, или просто проверив тест-кейсы в цикле в теле одного теста, но user experience будет хуже.

Мы-то все знаем, как писать использовать тру ООП в голом С, но при этом уровень шума при чтении такого кода будет заоблачным. В этом случае проблема аналогична.

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


A>>при том что с локальными функциями можно поставить точку останова на строчку с нужным тестом?

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

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

A>Приведённый выше пример страдает той же проблемой — провалится один тест, а проблем внутри может быть сразу много. Да и отлаживать тесты — это то ещё кощунство.

Вот именно эта проблема и решается параметризованными тестами!

Следующий тест:

[TestCase("(-Inf,+Inf)", Result = true)]
[TestCase("[0,1.5)", Result = true)]
[TestCase("(0,0)", Result = false)]
[TestCase("[0,-1.12)", Result = false)]
[TestCase("(Inf,-Inf]", Result = false)]
[TestCase(null, Result = false, ExpectedException = typeof(ArgumentNullException))]
public bool Test_Interval_Validity(string range)
{
    try
    {
        Interval.Parse(range);
        return true;
    }
    catch (FormatException)
    {
        return false;
    }
}

Тест-раннером разворачивается в 6 (!) независимых тест-кейсов, каждый из которых запускается независимо:



И если один из тест-кейсов упадет, то мы увидим в точности то, что упало:



Так что по-сути, параметризованные тесты — это такой себе простенький язык для генерации множества тест-кейсов, что вручную получить практически невозможно!

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

IT>>Зачем — это как раз мой вопрос.
Tom>зачем что? блин сломалась мыслечиталка

IT выше утверждал, что моки не нужны. Т.е. его вопрос, зачем нужны моки, как я понял.

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

ST>В данном случае смешиваются тест-кейс с тестовыми данными.

В смысле? В:

[TestCase("[0,1.5)", Result = true)]

не смешиваются и всё хорошо, а

check(test("[0,1.5)") == true);

смешиваются и ужас?
Вот ведь мощь декларативщины чего творит!

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

A>>прочитал этот пост в блоге, и не понял зачем эти атрибуты нужны.
A>>чем они лучше чем обычная локальная функция?

ST>В данном случае смешиваются тест-кейс с тестовыми данными.
нет. кейс в функции test, данные отдельно, после нее.

ST>При этом, как будет вести себя тест, если вторая строка свалится? Упадет или пойдет дальше?
с check() пойдет дальше, с require() остановится. я всегда использую require().

ST>Или этот велосипед накопит все поломанные тесты и сгенерирует AggregateException со всеми поломанными тестами? Будем ли мы видеть в тест-эксплорере один тест или 6?
можно и без исключений, каждый провалившийся check/require добавляет строчку в отчет.
тест-эксплорер не нужен, достаточно прочитать в отчете "все тесты OK", или список строчек в которых тесты провалились.

ST>Мы-то все знаем, как писать использовать тру ООП в голом С, но при этом уровень шума при чтении такого кода будет заоблачным. В этом случае проблема аналогична.
отнюдь. если говорить о коде, я вижу шум в виде "Result=" в параметризированных тестах, и не вижу шума в своем варианте.

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

IT>У меня дома три монитора один посередине 24-х дюймовый, нафига мне экономить? На гитхабе я код смотрю несколько раз в год, а дома каждый день.

у меня тоже широкий монитор, и экран выглядит вот так:
http://gyazo.com/3edd700fad4230deccdf5d8de678eaa4
ширина строки получается чуть больше 80 символов
если мы говорим о поддержке кода несколькими людьми, то у кого-то из них может оказаться 1 маленький монитор, например как у ноута.

IT>Так же очевидно, что дизайн можно сделать как стремящимся к зависимостям от чего-нибудь, так и не стремящимся. Если всё оправдывать наличием моков, то дизайн всячески и со страшной силой будет стремится к зависимостям. Это тоже очевидно. Я, к примеру, ни разу не видел ни одного приложения, где можно было сделать дизайн без моков. Поэтому и спрашиваю вас рассказать и показать.

ок, вот пример:

допустим мы пишем библиотеку, в ней есть функция "сделать сложную штуку", например downloadFile, writeFirmware и т.п.
чтобы она красиво интегрировалась с UI, функция принимает от пользователя некоторый коллбэк и дергает его чтобы сообщить что она сейчас делает

...
callback.finishedInitialization();
...
callback.obtainedCurrentVersion(major, minor);
...
callback.writeProgress(percent, speed);
...
if (callback.abortRequested())
    ...

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

здесь дизайн определяется задачей — "выполнить такой-то процесс; сделать поддержку UI"

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

ST>Так что по-сути, параметризованные тесты — это такой себе простенький язык для генерации множества тест-кейсов, что вручную получить практически невозможно!

Ясно, спасибо. Я так и подумал Надо будет поглядеть, а то мы всё, по старинке, вручную генерим такой набор.

--
С Уважением, Andir!