Стратегия выхода из статической зависимости

Question

В проекте, к которому я только что присоединился, достаточно широко используется шаблон команд для обработки вызовов на уровнях бизнес-логики проекта.

Уровни бизнес-логики построены как статические обработчики, обращающиеся к поставщикам. Затем команды вызывают эти статические обработчики.

Команда хочет улучшить покрытие тестами, и я хотел бы, чтобы мы больше двигались в сторону настоящего TDD, но использование статических обработчиков означает, что в командах есть жестко запрограммированная зависимость, и нет способа внедрить обработчики как зависимости и поэтому очень трудно выполнить модульное тестирование команд в отдельности.

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

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

protected override bool Process()
{
    this.user = SecurityHandler.ActivateUser(this.activationGuid);
    bool success = this.user != null;

    if (!success)
    {
        this.AddStatusMessage(StatusMessageType.Error, "/Commands/Security/ActivateUserCommand/IncorrectLink", true);
    }

    return success;
}

Answer 1

Статические методы / поля обычно вредят тестируемости - потому что это создает риск того, что тесты не будут изолированы.Один тест может установить какое-то статическое поле, изменив начальное состояние для test2.

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

Нет простого выхода ... переместите статические части в другой класс / объект и передайте его в объекты, которые должны получить к нему доступ.Это может означать добавление параметра к методам, которые в настоящее время используют вызов TypeName.StaticField для получения данных.

Обновление (для фрагмента размещенного кода): Я не вижу шаблон командыздесь ... в любом случае, чтобы получить тестируемый метод.

• Есть ли у SecurityHandler.ActivateUser какие-либо побочные эффекты?Отличается ли это во второй раз от вызова в первый раз?Если нет (т. Е. Это чистый сервисный вызов), не беспокойтесь об этом.
• если у ActivateUser есть побочные эффекты, вам придется поработать.Т.е. превратить статические методы в методы экземпляра и передать экземпляр SecurityHandler в содержащий тип Process ().Вы можете передать его в качестве параметра метода в Process () или установить ctor / свойство для содержащего типа.Выберите то, что вы считаете подходящим.

Answer 2

Инъекция зависимости (инверсия контроля)

Статические зависимости - это неприятный запах, и обычно можно использовать DI / IoC для удаления этого неприятного запаха.Найдите любой DI / IoC-фреймворк и используйте его.

Answer 3

Хотя это не помогает с точки зрения шаблонов проектирования, если вы хотите увеличить тестирование сейчас, вы всегда можете использовать что-то вроде Typemock Isolator или Telerik JustMock , которые позволяют вам макетируйте статические классы, пока вы конвертируете свой код из текущего дизайна. (Это коммерческие продукты).

Я бы сам этого не делал, так как есть опасность, что вы просто начнете полагаться на них и не будете беспокоиться о рефакторинге своего кода, чтобы сделать его тестируемым - одна из вещей, которые мне нравятся в TDD / автоматизированном тестировании, заключается в том, что он вызывает вам нужен код, который слабо связан и следует некоторым хорошим принципам проектирования, и подобные инструменты могут от него избавиться.