I have a service object with an interface explicitly defined for it. I like this because it let’s me unit test the things that need the service without having to worry about the implementation detail of the actual service.
public interface IMyService
public void DoSomething();
public void AnotherThingHere();
When I get to the implementation of this service and I start specifying the behavior through my specification/tests, I create a class that has a dependency on another interface – ISomeRepository. This repository is used in both methods of the actual service implementation.
For the “AnotherThingHere” method, I end up with several specification/tests because that method has some good business logic in it.
For the “DoSomething” method, though, the real implementation is only a pass-through to the repository and my specification/test ends up looking like this:
public class When_doing_something: ContextSpecification
public override void Context()
repo = MockRepository.GenerateMock<ISomeRepository>();
IMyService myService = new MyService(repo);
public void Should_do_something()
repo.AssertWasCalled(r => r.DoSomething());
I know this specification is necessary because I am using the “DoSomething” method of IMyService in other parts of the system. I think there is value in having an IMyService interface explicitly because it simplified the specification/tests for the parts of the system that need to use it, and decoupled the system to a point that made it much easier to code and change.
So my question is, do you see any real value in a specification/test name like “When doing something, should do something”? or should I be looking at this test from a different “style” or perspective?
I think this specification/test is valuable, but I also think the test name and observation name are silly since they say the same thing. Advice? Different naming suggestions? What am I missing or just not seeing? or is this ok and I’m just running on 25% brain power due to lack of sleep today?