Какая смелая структура выбора в библиотеке Unit Test для приложений Windows Store?
Когда я пишу модульные тесты, мне нравится использовать Rhino Mocks.
Итак, когда я начал свое первое приложение для Windows Store, я, естественно, начал с моих модульных тестов. Когда я попытался добавить RhinoMocks через NuGet, я получил следующую ошибку:
Не удалось установить пакет "RhinoMocks 3.6.1". Вы пытаетесь установите этот пакет в проект, целью которого является '.NETCore, Version = v4.5', но пакет не содержит сборки которые совместимы с этой структурой. Для большего информацию, обратитесь к автору пакета.
У меня была такая же проблема с Moq.
Есть ли насмешливая структура для .NETCor, Version = v4.5?
Ответы
Ответ 1
Большинство издевательских фреймворков основаны на Reflection.Emit
. К сожалению, Reflection.Emit
не находится в WinRT. Это означает, что вы не можете выполнять динамические прокси. (I.e. Время исполнения). Это оставляет предварительное поколение макетов, на которые ссылаются во время компиляции. Единственная структура, которую я знаю, является экспериментальной ветвью Moq: https://github.com/mbrit/moqrt
Ответ 2
Я сделал это для использования с Windows Phone 7, должен работать с Win 8, так как это только шаг сборки post:
http://dontcodetired.com/blog/post/Introducing-%28probably%29-The-Worlds-Only-Mocking-Framework-for-Windows-Phone-7-%28WP7%29.aspx
Ответ 3
Вот мои предложения, помните, что я еще не тестировал их. Здесь - ссылка на статью, в которой обсуждаются первые два варианта.
- TypeMock Isolator - дорого, но похоже, что это выполнит работу
- Microsoft Fakes (развивается из проекта в MSR под названием Moles)
- Вместо того, чтобы насмехаться (или делать инъекции зависимостей), вы можете использовать другой метод. Вы можете использовать параметризованную инъекцию и просто передавать информацию, необходимую для тестирования. Это сводится к большим объектам для делегатов и примитивов, что избавляет от необходимости насмешливую структуру. Здесь больше об этом, в том числе пример метода в действии.
Ответ 4
Собственно, Philipp Dolder, один из участников FakeItEasy разработал интересный и эффективный подход, основанный на портативных библиотеках классов.
http://www.planetgeek.ch/2013/02/01/fakeiteasy-and-windows-store-apps-are-becoming-friends/
В сущности, он предлагает следующее решение:
- Поместите весь ваш продуктивный код, который будет TDD-ed в библиотеку классов PCL, где вы выбираете любые целевые структуры, которые вы хотите поддерживать
- Создайте тестовую сборку как обычную библиотеку классов
- Добавьте ссылки на FakeItEasy и ваши тестовые рамки выбора (например, NUnit + FluentAssertions) на вашу сборку *.Test
- Поместите материал пользовательского интерфейса, который вы не можете протестировать, в проект приложения Windows Store.
Ответ 5
Я знаю, что исходный вопрос старый, но многие из нас все еще пытаются сделать издевательство в приложениях Windows Store.
Недавно я начал использовать MoqaLate, в котором говорится: "Mocking для приложений Windows Phone и Windows Store".
Это фактически физически создает MockingClasses после того, как вы построите свое решение.
Таким образом, после сборки у вас будет папка с некоторыми реализациями ваших макетов.
Я думаю, что это не лучший вариант. Быстрое издевательство будет идеальным, но в то же время оно создает для нас макеты.