Mock и Unit-тестирование

Требуется консультация о принципах работы с Mock во время юнит-тестирования.

У меня есть следующий код

public class CalendarICalParserHelper : ICalendarICalParserHelper
{
    protected CalendarICalParserHelper() { }

    public virtual Result<string> LoadResource(Uri url)
    {
        return LoadResource(url.ToString());
    }

    public virtual Result<string> LoadResource(string url)
    {
       //код работы с сетью.
    }

    public Result<List<UnavailableEntry>> GetParsedElements(Guid propertyId, string notes, string data)
    {
       //код парсинга
    }
}

Требуется протестировать данный класс юнит-тестами, а конкретно GetParsedElements(...). Метод LoadResource(Uri url) работает с сетью (скачивает файл по Url) и его необходимо "замокать". Реализацию метода GetParsedElements(...) "мокать" не нужно.

Что я сделал: наследовал данный класс у MockCalendarCalParserHelper. Перегрузил методы ("замокал") LoadResource(...) и получил следующий код:

public class MockCalendarCalParserHelper : CalendarICalParserHelper
{
    public MockCalendarCalParserHelper() : base() { }

    public override Result<string> LoadResource(Uri url)
    {
        return LoadResource(url.ToString());
    }

    public override Result<string> LoadResource(string url)
    {
        //возвращаю локальный файл. Не тяну его через сеть.
    }

    public new Result<List<UnavailableEntry>> GetParsedElements(Guid propertyId, string notes, string data)
    {
        return base.GetParsedElements(propertyId, notes, data);
    }
}

В результате в юнит-тестах при вызове LoadResource(...) возвращается локальный файл (string) и не скачивается из сети. Далее вызывается GetParsedElements(...) и проверяется корректность парсинга.

В проекте используется IoC, поэтому конструктор CalendarICalParserHelper() не публичный. Конструктор у MockCalendarCalParserHelper() публичный, т.к. этот класс используется только в юнит-тестах.

Верно ли я подошёл к решению вопроса с mock-классами или "моком" отдельных функций у класса? Может быть я не прав или есть лучшее решение, как "замокать" часть функций проверяемого класса, а часть оставить как есть для проверки (но при этом не дублировать код проверяемых методов)?

Используемая библиотека для моков - Rhino.


Ответы (0 шт):