How do you name xSpecification/BDD test classes so that they convey the intent? Especially in the Solution Explorer

Question

I've recently adopted strongly following BDD design along with usage of MSpec for implementing xSpecification tests. This has been leading to some rather insane class names that become hard to distinguish intent inside the solution explorer. Take for example:

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

Some of my initial thoughts have been perhaps to use solution folders and do something like

Given_I_am_logged_in \ When_I_view_my_some_company_super_things.cs

This would allow me to potentially drill down further

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

Has anyone had success doing something similar, or what have you found success with in naming xSpecification tests?

Tim Long · Answer 1 · 2011-12-09T17:56:37.527

Caveat: I'm not an expert at this and I work in isolation, but this is my personal take based on several months of trial and error.

There's an overload of the subject attribute [Subject(Type subjectType, string subject)]

Perhaps you could use the string parameter to document your concern, so perhaps you'd use something like:

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

-and-

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

Expanding on that a bit, if you are using the convention

Given the system is in this particular state
When this interesting thing happens
Then these are the consequences

That is another way of expressing the Arrange, Act, Assert pattern. The Given (Arrange) is your context, the preconditions for the test. The When (Act) is the activity you're testing and the Then (Assert) is where you verify expected behaviour.

in MSpec, I usually use this pattern:

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

So to try to use terms from your problem domain:

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...
}

Did you know with MSpec combined with Machine.Fakes you can compose classes to share functionality instead of just sharing functionality through inheritance? https://github.com/BjRo/Machine.Fakes — Chris Marisic, Dec 13 '11 at 13:19
I didn't know that. I'm still trying to master MSpec and Moq, but what would be interesting if you have the time is for you to rework my example code above using Machine.Fakes and post it in a seperate answer so we can compare and contrast. — Tim Long, Dec 13 '11 at 17:47
Tim, take a look at https://gist.github.com/1473259 this is a test skeleton I have from code writing using Machine.Fakes in conjunction with MSpec. IWebLogger is an interface that in real world will write to ELMAH, previously I just used static methods to write exceptions but this lead to hard to test code to make sure no errors actually happened (or to get the error that's expected). This lead me to replace it's usage with proper interfaces, the InMemoryLoggingConfiguration has very little relevance to the test at hand so it doesn't make sense to be forced to inherit from it as a base class. — Chris Marisic, Dec 13 '11 at 18:39
This allows me to connect a specific List to my MemoryLogger concrete class that is easily accessible in my spec test. Another interesting note, the code where I register The>().WhenToldTo(x => x.AsQueryable()).Return(ThingsRepository.AsQueryable()); this is actually mocking a dependency to an EF Code first IDbSet collection (which is directly an iqueryable). — Chris Marisic, Dec 13 '11 at 18:41

score 1 · Answer 2 · answered Dec 08 '11 at 17:34

1

Group all the test classes for a given object under one file e.g. SuperThingTests would contain all of your tests around the SuperThing class.

answered Dec 08 '11 at 17:34

Michael Brown

9,041
1
28
37

The 2 main things I see with this option, contextual information becomes buried (I tried to do some reflection on whether that information is **truly** meaningful or not, and it was hard for me to say it's not), past that the main issue I would see is developer contention on same file, but I guess that would relate to how feature rich each bucket file is? – Chris Marisic Dec 08 '11 at 17:47

How do you name xSpecification/BDD test classes so that they convey the intent? Especially in the Solution Explorer

2 Answers2