Блог

Проблема

Мы хотели бы найти способ выборочно переопределять некоторые методы класса, но не изменять немного его определения.
Кроме того, мы хотели бы, чтобы переопределение было необязательным (т. е. не обязательным). То есть мы можем переопределить его, когда захотим, но мы также можем отказаться от написания какой-либо строки кода для него, когда мы этого не хотим.

Пример использования

Предположим, у нас есть класс, предоставляющий данные, назовем его Model .
У нас есть другой класс, который использует эти данные. Это View .

Теперь мы хотели бы провести интеграционные тесты для View . Для удобства мы хотели бы изменить некоторую часть предоставленных данных Model , оставив другую часть как есть.
Поскольку мы хотим изменить возвращаемые данные Model , это означает, что мы должны переопределить некоторые из их поведения (т. е. методы). Однако, поскольку это всего лишь тест, естественно, мы не хотим изменять исходный код Model .

Предыдущие Попытки

Оформитель

Первый подход , который я мог придумать Model , — это, скажем IModel , извлечение интерфейса и создание для него декоратора, такого как

 public interface IModel
{
    string GetSomething();
    string GetOther(); // We want to override this
}

public class Model : IModel // This is the real model
{
}

public class ModelWrapper : IModel
{
    private IModel _internal; // Should be an instance of Model

    public string GetSomething() => _internal.GetSomething(); // we want to keep the behavior of original model for this method

    public string GetOther() // We want to change the behavior of this one
    {
        return "something for testing";
    }
}
 

Преимущество такого подхода заключается в том, что мы будем иметь полный контроль над макетом.
Однако недостатком было бы то, что мы должны продолжать поддерживать ModelWrapper .
Когда IModel что-то меняется, мы вынуждены обновлять ModelWrapper .
К сожалению, их у нас много IModel , и они часто меняются. Поддержание этих классов-оболочек довольно тревожно.

Издевательская библиотека

Другим подходом, который я мог бы придумать, было бы использование для этого библиотеки насмешек, такой как NSubtitute или Moq.
С помощью библиотеки насмешек мы можем указать поведение методов интерфейса без изменения кода его реализующих классов.

Нам не нужно указывать поведение каждого метода интерфейса. Мы можем издеваться над ними выборочно.
Поведение разблокируемых методов автоматически определяется макетной библиотекой. Обычно они просто возвращают значение по умолчанию возвращаемого типа.

Однако значения по умолчанию иногда могут быть недостаточно хороши для нас, потому что нам может понадобиться, чтобы они находились в каком-то определенном диапазоне, или IView это будет выглядеть странно. Лучшим резервным вариантом может быть использование наших (существующих) конкретных классов. Обычно они дают правильные результаты.

До сих пор я не могу найти издевательскую библиотеку, которая могла бы вернуться к конкретному классу. NSubstitute и Moq поддерживают следующие две вещи, но они не совсем идеальны:

1. Макет интерфейса. Методы, над которыми явно не издеваются, возвращают значения по умолчанию. Вид может показаться странным.
2. Поиздеваться над классом. Переопределить можно только виртуальные методы. Нам нужно изменить код наших конкретных классов, если мы хотим издеваться над ними таким образом.

Каковы другие хорошие способы достижения этой цели?
Или я решаю не ту проблему? Может быть, есть какие-то другие методы для удовлетворения таких потребностей в тестировании?

Если класс не запечатан, вы можете сделать методы, которые хотите переопределить, виртуальными, а затем переопределить их в производном классе. Это оказало бы минимальное влияние на исходный код и не требовало бы никакой библиотеки.

Обратите внимание, что производный класс должен использоваться только для тестов и должен быть исключен из окончательного кода, возможно, с помощью internal . Это простое решение, но в некотором роде несовершенное и не является реальной имитацией класса, просто простое переопределение для выполнения некоторых экспериментов и тестов.