Модульные тесты и логика проверки

• Позвольте Модульным тестам (множественное число) против Проверить методов, подтверждают их корректное функционирование.
• Позвольте Модульным тестам (множественное число) против метода CreateUser, подтверждают его корректное функционирование.

Если CreateUser просто обязан называть проверить методы, но не обязан принимать решения проверки сам, то тесты против CreateUser должны подтвердить то требование.

Определенно необходимо протестировать методы проверки.

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

Вы, кажется, смешиваете Проверку и Дизайн Контракта.

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

Дизайн Контракта удостоверяется, что Ваш код может выполниться, не выдавая исключения позже (даже без них, Вы получили бы исключение, но намного позже и вероятно более неясное).

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

Таким образом, наконец запишите тесты логики проверки, когда Вы хотите к товарищеской встрече, уведомляют пользователя, что он имеет ошибочный. Иначе используйте Дизайн Контракта и продолжайте выдавать исключения.

Какова ответственность Вашего класса бизнес-логики, и это делает что-то кроме проверки? Я думаю, что испытал бы желание переместить стандартные программы проверки в собственный класс (UserValidator) или несколько классов (UserDetailsValidator + UserCredentialsValidator) в зависимости от Вашего контекста и затем обеспечить насмешки для тестов. Таким образом, Ваш класс теперь посмотрел бы что-то как:

public User CreateUser(string username, string password, UserDetails details)
{
    if (Validator.isValid(details, username, password)) {
       // what happens when not valid
    }

    // create and return user
}

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

Я добавил бы набор теста для каждого метода ValidateXXX. Затем в CreateUser создают 3 тестовых сценария для проверки, что происходит, когда каждый из ValidateUserDetails, ValidateUsername и ValidatePassword перестал работать, но другой успешно выполняющийся.

Я использую Lokad Общая Библиотека для определения бизнес-правил проверки. Вот то, как я тестирую угловые случаи (образец от открытого исходного кода):

[Test]
public void Test()
{
  ShouldPass("rinat.abdullin@lokad.com", "pwd", "http://ws.lokad.com/TimeSerieS2.asmx");
  ShouldPass("some@nowhere.net", "pwd", "http://127.0.0.1/TimeSerieS2.asmx");
  ShouldPass("rinat.abdullin@lokad.com", "pwd", "http://sandbox-ws.lokad.com/TimeSerieS2.asmx");

  ShouldFail("invalid", "pwd", "http://ws.lokad.com/TimeSerieS.asmx");
  ShouldFail("rinat.abdullin@lokad.com", "pwd", "http://identity-theift.com/TimeSerieS2.asmx");
}

static void ShouldFail(string username, string pwd, string url)
{
  try
  {
    ShouldPass(username, pwd, url);
    Assert.Fail("Expected {0}", typeof (RuleException).Name);
  }
  catch (RuleException)
  {
  }
}

static void ShouldPass(string username, string pwd, string url)
{
  var connection = new ServiceConnection(username, pwd, new Uri(url));
  Enforce.That(connection, ApiRules.ValidConnection);
}

Где правило ValidConnection определяется как:

public static void ValidConnection(ServiceConnection connection, IScope scope)
{
  scope.Validate(connection.Username, "UserName", StringIs.Limited(6, 256), StringIs.ValidEmail);
  scope.Validate(connection.Password, "Password", StringIs.Limited(1, 256));
  scope.Validate(connection.Endpoint, "Endpoint", Endpoint);
}

static void Endpoint(Uri obj, IScope scope)
{
  var local = obj.LocalPath.ToLowerInvariant();
  if (local == "/timeseries.asmx")
  {
    scope.Error("Please, use TimeSeries2.asmx");
  }
  else if (local != "/timeseries2.asmx")
  {
    scope.Error("Unsupported local address '{0}'", local);
  }

  if (!obj.IsLoopback)
  {
    var host = obj.Host.ToLowerInvariant();
    if ((host != "ws.lokad.com") && (host != "sandbox-ws.lokad.com"))
      scope.Error("Unknown host '{0}'", host);
  }

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

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

PS: обратите внимание, что примитивные правила использовали в этом демонстрационном составном правиле (т.е. StringIs. ValidEmail или StringIs. Ограниченный), полностью тестируются самостоятельно и таким образом не нуждаются в чрезмерных модульных тестах.