Как вы называете тестовые классы xSpecification / BDD, чтобы они передавали намерение? Особенно в Solution Explorer - PullRequest
3 голосов
/ 08 декабря 2011

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

[Subject(typeof(MuchGoodServiceOrchestrator))]
public class Given_i_am_a_logged_user_and_view_my_some_company_super_things 
    : WithSubject<MuchGoodServiceOrchestrator>

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

Given_I_am_logged_in \ When_I_view_my_some_company_super_things.cs

Это позволило бы мне продолжить детализацию

Given_I_am_logged_in \ And_things_are_good \ When_I_view_my_some_company_super_things.cs Given_I_am_logged_in \ And_things_are_bad \ When_I_view_my_some_company_super_things.cs

У кого-нибудь был успех, когда он делал что-то подобное, или с чем вы добились успеха в именовании тестов xSpecification?

Ответы [ 2 ]

3 голосов
/ 09 декабря 2011

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

Перегрузка атрибута субъекта [Subject(Type subjectType, string subject)]

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

[Subject(typeof(MuchGoodServiceOrchestrator), "Logged in"]

-и-

[Subject(typeof(MuchGoodServiceOrchestrator), "Not logged in"]

Более подробно об этом, если вы используете соглашение

  • Учитывая , система находится в этом конкретном состоянии
  • Когда происходит эта интересная вещь
  • Тогда это последствия

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

в MSpec, я обычно использую этот шаблон:

public class when_doing_domething : with_context
{
  It should_behave_like_this;  // One or more assertions.
  It should_also_behave_like_this;
}

Итак, чтобы попытаться использовать термины из вашего проблемного домена:

public class with_logged_in_user
{
  protected static User User;
  protected static MuchGoodServiceOrchestrator sut;
  // Arrange
  Establish context =()=> 
  {
    User = new User() { /* initialize the User object as a logged in user */ };
    sut = new MuchGoodServiceOrchestrator(User); // Dependency injection
  };
}

public class with_anonymous_user
{
  protected static User User;
  protected static MuchGoodServiceOrchestrator sut;
  // Arrange
  Establish context =()=> 
  {
    User = new User() { /* initialize the User object as anonymous or not logged in */ };
    sut = new MuchGoodServiceOrchestrator(User); // Dependency injection
  };
}

[Subject(typeof(MuchGoodServiceOrchestrator), "Logged in")]
public class when_viewing_things_as_a_logged_in_user : with_logged_in_user
{
  // Act
  Because of =()=> sut.CallTheCodeToBeTested();
  // Assert
  It should_do_this =()=> sut.Member.ShouldEqual(expectedValue); // Assert
}

[Subject(typeof(MuchGoodServiceOrchestrator), "Not logged in")]
public class when_viewing_things_while_not_logged_in : with_anonymous_user
{
  // Etc...
}
1 голос
/ 08 декабря 2011

Сгруппируйте все тестовые классы для данного объекта в один файл, например. SuperThingTests будет содержать все ваши тесты вокруг класса SuperThing.

...