Поблочное тестирование вход в систему в ASP.NET

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

1. Начните с размышлений о том, чего вы пытаетесь достичь, не на уровне отдельного теста, а о том, что вы пытаетесь сделать. Если ваша задача (пользовательская история) включает захват некоторых учетных данных и попытку аутентификации текущего пользователя на основе этих учетных данных, то начните с этого и продолжайте свой путь вниз. Похоже, вы движетесь в этом направлении, только застреваете на следующих шагах.

2. При работе над индивидуальным тестом подумайте об этом с точки зрения ожидаемого поведения , а не просто проверки некоторых входных и выходных данных. Представьте, что вы используете этот компонент, и просто напишите строку кода так, как вы хотите. Пусть эта часть поможет управлять интерфейсом / контрактом вашего сервиса. Вы должны задать себе вопрос: «Если бы я вызвал этот метод, как бы я узнал, что он работает? Что я от него ожидаю?» Это определит, какие утверждения вам нужно сделать.

3. Определите, каковы ваши внешние зависимости, и вместо этого используйте абстракции (принцип инверсии зависимостей). Если эти зависимости важны для вас как часть проверки вашего поведения, используйте внедрение зависимостей , чтобы вы могли использовать в своем тесте макет .

4. Всегда, всегда, всегда следуйте этому порядку [напишите свой тест, посмотрите, как он потерпит неудачу, код для успешного прохождения, рефакторинг]. УЧИТЕСЬ НА МОИХ ОШИБКАХ !!! Поверьте мне, это не подлежит обсуждению. В противном случае вы можете обвинить в своих проблемах TDD, если он не используется должным образом.

Хорошо, так что, сопоставив все это со своим примером и некоторыми хорошо предоставленными тестовыми примерами от lance , мы мог бы сделать что-то вроде этого:

[Test]
public void ShouldAuthenticateValidUser()
{
    IMyMockDa mockDa = new MockDataAccess();
    var service = new AuthenticationService(mockDa);

    mockDa.AddUser("Name", "Password");

    Assert.IsTrue(service.DoLogin("Name", "Password"));

    //Ensure data access layer was used
    Assert.IsTrue(mockDa.GetUserFromDBWasCalled);
}

[Test]
public void ShouldNotAuthenticateUserWithInvalidPassword()
{
    IMyMockDa mockDa = new MockDataAccess();
    var service = new AuthenticationService(mockDa);

    mockDa.AddUser("Name", "Password");

    Assert.IsFalse(service.DoLogin("Name", "BadPassword"));

    //Ensure data access layer was used
    Assert.IsTrue(mockDa.GetUserFromDBWasCalled);
}

Хорошо, так что там много чего происходит, и, возможно, еще много нужно исследовать. Однако вы можете начать понимать, как можно провести тщательное тестирование, используя лучший дизайн. В приведенных выше примерах важно отметить, что Mock Object настраивается индивидуально, но вам не нужно проходить через всю эту боль. Существует множество Mocking Framework. Например, при использовании RhinoMocks ваш тест будет выглядеть так:

[Test]
public void ShouldAuthenticateValidUser()
{
    var mockRepo = new MockRepository();
    var mockDa = mockRepo.DynamicMock<IMyMockDa>();

    var service = new AuthenticationService(mockDa);

    using(mockRepo.Record())
    {
        //I realize this is a terrible method and should not exist if you
        // care about security, but for demonstration purposes...
        Expect.Call(mockDa.GetPassword("User")).Return("Password");
    }
    using(mockRepo.Playback())
    {
        Assert.IsTrue(service.DoLogin("User", "Password"));
    }
}

Привыкайте сначала делать что-то вручную, чтобы понять концепции, а затем переходите к использованию фреймворка. Ух! Много информации, но, как видите, TDD - это целая философия дизайна. Однако это приведет к более чистому коду, лучшему дизайну и меньшему количеству ошибок.