RhinoMock: Mocks против StrictMocks против DynamicMocks
Для тех, кто ищет решение этой проблемы, в настоящий момент все сводится к тому, что у него есть заставка, реализующая класс MvxSplashScreenAppCompatActivity.
Softlion работает над PR, который снимет это требование.
Вы можете отслеживать текущее состояние проблемы здесь: Вкладки с MVVMCross 6.2+
2 ответа
Строгий имитатор - это имитация, которая вызовет исключение, если вы попытаетесь использовать какой-либо метод, который не был явно настроен для использования.
Динамический (или свободный) макет не вызовет исключения, если вы попытаетесь использовать не настроенный метод, он просто вернет null значение по умолчанию из метода и продолжит работу.
Настоятельно рекомендуется использовать динамические моки, поскольку строгие моки обычно превращаются в кошмар обслуживания. Вот хорошая запись в блоге , в которой есть пример кода, где строгий и динамический, а также почему строгие имитаторы обычно являются плохой идеей.
Сильно не согласен по этому вопросу.
Можно утверждать, что разработка через тестирование невозможна при использовании динамических макетов, потому что то, что вы тестируете, не обязательно то, что вы реализуете.
Представьте, что вы добавили цикл foreach, где вы сделали вызов db внутри цикла. Это очень плохо масштабируется. Если бы вы использовали динамические mock для моделирования ваших зависимостей, вы бы потенциально пропустили mocking для вызовов db, следовательно, пропустили проблему масштабируемости, потому что вам не нужно было бы строго mock для каждого вызова db.
public void myMethod()
{
externalMethod1.doSomething();
foreach()
{
externalDbCall.doSql();
}
}
public void testMyMethodWithDynamicMocksPassesAndMissesDbCallInLoop()
{
expect(externalMethod1.doSomething();
}
public void testMyMethodWithStrictMocksFailsAndHighlightsDbCallInLoop()
{
expect(externalMethod1.doSomething();
}