Я працюю над .NET 4.0 за допомогою C # у Windows 7.
Я хочу перевірити зв'язок між деякими методами, використовуючи макет. Єдина проблема полягає в тому, що я хочу це зробити, не впроваджуючи інтерфейс. Це можливо?
Я просто прочитав багато тем та кілька підручників про макетні об'єкти, але всі вони раніше використовували макет інтерфейсів, а не класів. Я намагався використовувати фреймворки Rhino та Moq.
Відповіді:
Просто позначте будь-який спосіб, який вам потрібно підробляти, як virtual(а не приватний). Тоді ви зможете створити підробку, яка може замінити метод.
Якщо ви використовуєте new Mock<Type>і у вас немає конструктора без параметрів, тоді ви можете передати параметри як аргументи вищезазначеного виклику, оскільки він приймає типparam Objects
Більшість глузливих фреймворків (включаючи Moq та RhinoMocks) генерують проксі-класи як замінник вашого знущаного класу та замінюють віртуальні методи поведінкою, яку ви визначаєте. Через це ви можете знущатися над інтерфейсами або віртуальними методами на конкретних або абстрактних класах. Крім того, якщо ви знущаєтесь із конкретного класу, вам майже завжди потрібно надати безпараметричний конструктор, щоб знущальний фреймворк знав, як створити екземпляр класу.
Чому неприязнь до створення інтерфейсів у вашому коді?
За допомогою MoQ ви можете висміяти конкретні класи:
var mocked = new Mock<MyConcreteClass>();
але це дозволяє замінити virtualкод (методи та властивості).
new Mock<MyConcreteClass>(param1, anotherParam, thirdParam, evenMoreParams);
Я думаю, що краще створити інтерфейс для цього класу. І створити модульний тест за допомогою інтерфейсу.
Якщо у вас немає доступу до цього класу, ви можете створити адаптер для цього класу.
Наприклад:
public class RealClass
{
int DoSomething(string input)
{
// real implementation here
}
}
public interface IRealClassAdapter
{
int DoSomething(string input);
}
public class RealClassAdapter : IRealClassAdapter
{
readonly RealClass _realClass;
public RealClassAdapter() => _realClass = new RealClass();
int DoSomething(string input) => _realClass.DoSomething(input);
}
Таким чином, ви можете легко створити макет для вашого класу за допомогою IRealClassAdapter.
Сподіваюся, це працює.
Стандартні фреймворки для насмішок створюють проксі-класи. Це причина, чому вони технічно обмежені інтерфейсами та віртуальними методами.
Якщо ви хочете знущатись і над "звичайними" методами, вам потрібен інструмент, який працює з інструментарієм замість генерації проксі. Наприклад, MS Moles і Typemock можуть це зробити. Але перший має жахливий "API", а другий є комерційним.
Якщо ви не можете змінити тестований клас, тоді єдиним варіантом, який я можу запропонувати, є використання MS Fakes https://msdn.microsoft.com/en-us/library/hh549175.aspx . Однак MS Fakes працює лише в декількох виданнях Visual Studio.
Якщо гірше стає гіршим, ви можете створити пару інтерфейсу та адаптера. Ви б змінили всі способи використання ConcreteClass, щоб використовувати інтерфейс замість цього, і завжди передавати адаптер замість конкретного класу у виробничому коді.
Адаптер реалізує інтерфейс, тому макет може також реалізувати інтерфейс.
Це більше риштування, ніж просто створення методу віртуальним або просто додавання інтерфейсу, але якщо у вас немає доступу до джерела для конкретного класу, це може вивести вас з прив’язки.
Я зіткнувся з чимось подібним в одному зі старих та застарілих проектів, в яких я працював, який не містить жодного інтерфейсу чи найкращої практики, а також занадто важко змусити їх знову будувати речі або переробляти код через зрілість проектного бізнесу, тому у своєму проекті UnitTest я використовував для створення Wrapper-класів над класами, над якими я хочу знущатися, та інтерфейсу реалізації оболонки, який містить усі мої необхідні методи, які я хочу налаштувати та працювати з ними, тепер я можу знущатись над обгорткою замість реального класу.
Наприклад:
Служба, яку ви хочете перевірити, яка не містить віртуальних методів або інтерфейсу реалізації
public class ServiceA{
public void A(){}
public String B(){}
}
Обгортка до moq
public class ServiceAWrapper : IServiceAWrapper{
public void A(){}
public String B(){}
}
Інтерфейс обгортки
public interface IServiceAWrapper{
void A();
String B();
}
У юніт-тесті тепер можна знущатись над обгорткою:
public void A_Run_ChangeStateOfX()
{
var moq = new Mock<IServiceAWrapper>();
moq.Setup(...);
}
Це може бути не найкращою практикою, але якщо правила проекту змушують вас таким чином, зробіть це. Також помістіть усі свої обгортки всередину вашого проекту Unit Test або Helper, вказаного лише для модульних тестів, щоб не перевантажувати проект непотрібними обгортками або адаптерами.
Оновлення: Ця відповідь пішла більше року, але цього року я зіткнувся з багатьма подібними сценаріями з різними рішеннями. Наприклад, так просто використовувати Microsoft Fake Framework для створення макетів, підробок і заглушок і навіть тестування приватних та захищених методів без будь-яких інтерфейсів. Ви можете прочитати: https://docs.microsoft.com/en-us/visualstudio/test/isolating-code-under-test-with-microsoft-fakes?view=vs-2017