ASP.net Тестовые соглашения о присвоении имен MVC RTM

I think this is a perfect example of why rigid naming conventions for unit tests are unattractive.

Your proposed scheme will only work when you have two method overloads: one with and one without parameters. It doesn't extend to the scenario where you have more than one overload with different parameters.

Personally I prefer a much looser naming convention that can be summarized as

[Action][Will|Should|Is|...][Result]

This gives me the flexibility to name my tests

SutIsPathResolutionCommand
ExecuteWithNullEvaluationContextWillThrow
ExecuteWillAddDefaultClaimsTransformationServiceWhenNoConnectionServiceIsAvailable

I must admit that I rarely read the name of the test anyway. Instead, I read the specification of what it does (i.e. the test code). The name is just not that important to me.

Я использую следующий формат, который мне очень подходит:

[TestFixture]    
public class Log_in_with_parameters_should
{
    [Test]
    public void Return_the_log_in_view() {}
}

[TestFixture]    
public class Log_in_without_parameters_should
{
    [Test]
    public void Return_the_log_in_view_when_the_authentication_failed() {}

    [Test]
    public void Redirect_to_the_profile_when_the_authentication_passed() {}
}

Один из вариантов, который мне не особенно нравится, это дать экшенам контроллера разные имена, но затем переименовать их, используя атрибут ActionName:

public ActionResult Login() {
    // ... code ...
    return View();
}

[HttpPost]
[ActionName("Login")]
public ActionResult LoginPost(... some params ...) {
    // ... more code ...
    return View();
}

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

Возможно, я не отвечаю на ваш вопрос, но я хочу поделиться тем, чем занимаюсь. Я не следую определенному соглашению об именах, но я стараюсь давать имена, которые объясняют, какой метод тестирования пытается протестировать. В некоторых случаях, когда мне нужно больше объяснений, я добавляю описание [Тест («Этот тест оценивает, на сколько вопросов ответил конкретный пользователь»)].

Прежде всего нужно убедиться, что тесты более читабельны и понятны.

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

Имейте в виду, что такое именование тестов более "TDD oreigned" и не BDD - имена тестов BDD должны быть связаны с правилами и "поведением":

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