Хотелось бы иметь хороший инструментарий ( 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>>Встречный вопрос. А чем мок лучше не мока. Я вот точно могу сказать чем он хуже. А именно необходимостью использования интерфейсов, что в свою очередь напрочь убивает навигацию по коду и существенно снижает читаемость и понимабельность кода приложения.

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

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

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

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