More New Conventions for How I Organize My Tests!!

As the current project I am on is getting fairly large now, I just recently switched around the way I organize my tests. Here is a sample concern pulled from a main class in my application (smart client based):

public class ApplicationControllerSpecs

{

public abstract class concern : observations_for_a_sut_with_a_contract<IApplicationController, ApplicationController>

{

protected IApplicationShellView shell_presenter;

}

[Concern(typeof (ApplicationController))]

public class when_starting_up : concern

{

context c = () =>

{

application_shell = the_dependency<IApplicationShellPresenter>();

start_all_modules = the_dependency<IStartAllModules>();

event_aggregator = the_dependency<IEventAggregator>();

};

because b = () =>

sut.start();

it should_start_the_application_shell = () =>

application_shell.received(x => x.start());

it should_start_all_of_the_application_modules = () =>

start_all_modules.received(x => x.run());

it should_register_itself_as_a_listener_with_the_event_aggregator = () =>

event_aggregator.received(x => x.register_listener(sut));

static IApplicationShellPresenter application_shell;

static IStartAllModules start_all_modules;

static IEventAggregator event_aggregator;

}

}

Notice how at the top I am now creating a container class which is named {SUT}specs:

public class ApplicationControllerSpecs

All of the concerns for the ApplicationController will be housed inside this class. From an organizational perspective I can now have a superclass for all of my concerns for a particular SUT named concern:

public abstract class concern : observations_for_a_sut_with_a_contract<IApplicationController, ApplicationController>

{

protected IApplicationShellView shell_presenter;

}


Before, I would place my concerns directly at the root of the file (not nested inside a container class), this meant that when I went to derive a concern from a base concern, I would have to filter through a big ReSharper list of all of the base test classes in the solution that started with the word concern. Because I was following a convention of “concern_for_[sut]”, I would see more than I wanted. Now when I am inside of a container class and am writing a concern that I want to derive from its parent concern,typing con followed by CTRL-SPACE will only give me a very small set of options. I also don’t need to come up with a fancy name for the initial concern superclass. I can just call it concern. Each *Specs file in my current application follows this convention, and each one has an initial superclass named concern. You don’t need the superclass, I just find it a convenient place to put fields etc that can often crowd up the test, common results etc.
Develop With Passion!!

Comments