TDD — хотите протестировать мой сервисный уровень с поддельным репозиторием, но как?

Вам нужно использовать внедрение зависимостей. UserRepository является зависимостью вашего класса RegistrationService. Чтобы сделать ваши классы должным образом пригодными для модульного тестирования (т. е. отдельно от их зависимостей), вам нужно «инвертировать» то, что управляет созданием вашей зависимости. В настоящее время вы имеете прямой контроль и создаете их внутри. Просто инвертируйте этот элемент управления и позвольте чему-то внешнему (например, контейнеру IoC, такому как Castle Windsor) внедрить их:

public class RegistrationService: IRegistrationService
{
    public RegistrationService(IRepository<User> userRepo)
    {
        m_userRepo = userRepo;
    }

    private IRepository<User> m_userRepo;

    public void Register(User user)
    {
        // add user, etc with m_userRepo
    }
}

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

Внедрение зависимостей может очень пригодиться для таких вещей:

public class RegistrationService: IRegistrationService
{
    public void Register(User user)
    {
        this(user, new UserRepository());
    }

    public void Register(User user, IRepository<User> userRepository)
    {
        // add user, etc
    }

}

Таким образом, вы получаете возможность использовать UserRepository по умолчанию и передавать настраиваемый (Mock или Stub для тестирования) IRepository для всего, что вам нужно. Вы также можете изменить область действия метода 2-го регистра, если вы не хотите подвергать его воздействию всего.

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

public class RegistrationService: IRegistrationService
{
    public void Register(User user)
    {
        this(user, IoC.Resolve<IRepository<User>>());
    }

    public void Register(User user, IRepository<User> userRepository)
    {
        // add user, etc
    }

}

Существует много контейнеров IoC, как указано в ответах других людей, или вы можете откатить свой собственный.

Что вы должны делать, так это использовать инверсию управления или инъекцию зависимостей.

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

Существует очень много контейнеров IOC, Unity, Ninject, Castle Windsor и StructureMap, и это лишь некоторые из них.

Я просто хотел внести ясность: во время ваших модульных тестов я не уверен, что вы действительно захотите использовать контейнер IOC. Интеграционные тесты, конечно, но для модульных тестов просто обновите объект, который вы тестируете, и предоставьте свою подделку во время этого процесса. Контейнеры IOC, по крайней мере, IMO, помогают на уровне тестирования приложений или интеграции и упрощают настройку.

Ваши модульные тесты, вероятно, должны оставаться «чистыми» и работать только с объектами, которые вы пытаетесь протестировать. По крайней мере, это то, что работает для меня.

Просто чтобы добавить немного ясности (или, возможно, нет) к тому, что все сказали, то, как в основном работает IOC, вы говорите ему заменить X на Y. Итак, что вы должны сделать, это принять IRepository (как заявили другие) как параметр а затем в IOC вы бы сказали заменить IRepository на MockedRepository (например) для этого конкретного класса.

Если вы используете IoC, который позволяет инициализировать web.config, переход от dev к prod становится очень плавным. Вы просто изменяете соответствующие параметры в конфигурационном файле, и вы уже в пути — без необходимости прикасаться к коду. Позже, если вы решите перейти к другому источнику данных, вы просто отключите его, и все готово.

IoC — это забавная штука.

С другой стороны, вы можете сделать это и без внедрения IOC, если все, что вы хотите сделать, это модульное тестирование. Вы можете сделать это, перегрузив конструктор, чтобы он принимал IRepository, и просто передав таким образом свое издевательское репо.

Я сейчас над чем-то работаю, ну, почти дословно. Я использую MOQ для макета прокси-экземпляра моего IUserDataRepository.

С точки зрения тестирования:

//arrange
var mockrepository = new Mock<IUserDataRepository>();
// InsertUser method takes a MembershipUser and a string Role
mockrepository.Setup( repos => repos.InsertUser( It.IsAny<MembershipUser>(), It.IsAny<string>() ) ).AtMostOnce();

//act
var service = new UserService( mockrepository.Object );
var createResult = service.CreateUser( new MembershipUser(), "WebUser" );

//assert
Assert.AreEqual( MembershipCreateUserResult.Success, createResult );
mockrepository.VerifyAll();

MOQ также можно использовать для создания определенных исключений, чтобы мой UserService можно было протестировать в этих ситуациях.

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

Вы можете использовать контейнер IOC, а затем зарегистрировать другой репозиторий.

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