Насмешка Статических методов с помощью Насмешек Носорога
Я думаю, что это небольшое редактирование - то, что тебе нужно.
if name == "<name>":
file = open("<name>.txt", "r")
wishlist = file.readlines()
wishlist=[i.replace('{','') for i in wishlist] # removes all {s from all indices
wishlist=[i.replace('}','') for i in wishlist] # removes all }s from all indices
listtext.setText(wishlist)
6 ответов
Можно ли издеваться над статическим методом используя Rhino.Mocks
Нет, это невозможно.
TypeMock может сделать это, потому что он использует профилировщик CLR для перехвата и перенаправления вызовов.
RhinoMocks, NMock и Moq не могут этого сделать, потому что эти библиотеки проще; они не используют API CLR-профилировщика. Они проще в том, что они используют прокси для перехвата виртуальных членов и вызовов интерфейса. Недостатком этой простоты является то, что они не могут насмехаться над определенными вещами, такими как статические методы, статические свойства, запечатанные классы или не виртуальные методы экземпляров.
Перенесите вызов статического метода в виртуальный метод экземпляра в другом классе, затем дразните это.
Единственной ложной платформой, что я знаю этого поддержки, дразнящие помехи, является TypeMock.
Как предложенный Rytmis, необходимо перенести помехи во что-то (т.е. класс экземпляра с виртуальными методами или интерфейсом), что можно затем дразнить.
Я издевался над использованием moq, я не думаю, что мы можем имитировать статические члены, используя это, потому что moQ создает новый прокси для цели (класса или интерфейса). Таким образом, можно издеваться только над наследуемыми членами (виртуальными в случае класса, общедоступными с точки зрения интерфейса). Очевидно, что статические члены не наследуются, отсюда и проблема.
Это самый большой недостаток Rhino Mocks. Я не знаю, возможно ли для Rhino Mocks реализовать это без переосмысления того, как он делает свое издевательство.
Если вы не можете использовать TypeMock для перехвата вызова метода, рекомендуется использовать шаблон для создания прокси, который перенаправляет интересующие вас невиртуальные или статические методы. тестирование, затем установите ожидание на прокси. В качестве иллюстрации рассмотрим следующие классы.
class TypeToTest
{
public void Method() { }
}
interface ITypeToTest
{
void Method();
}
class TypeToTestProxy : ITypeToTest
{
TypeToTest m_type = new TypeToTest();
public void Method() { m_type.Method(); }
}
Создав этот прокси-сервер, вы теперь можете использовать ITypeToTest вместо того, где вы проходили или устанавливали экземпляр TypeToTest , убедившись, что реализация по умолчанию использует TypeToTestProxy , поскольку он перенаправляет к реальной реализации. Затем вы можете создать макет ITypeToTest в своем тестовом коде и установить соответствующие ожидания.
Обратите внимание, что создание этих прокси может быть очень утомительным, подверженным ошибкам и трудоемким. Для решения этой проблемы я поддерживаю библиотеку и набор инструментов, которые создают для вас сборки, содержащие эти типы. Пожалуйста, обратитесь к этой странице для получения дополнительной информации.