If you read my previous posts about [Fluent] Specification Extensions then you know that I'm still in an experimental phase of this idea.
There are two more things I've found that are going against the specification extensions idea. The first one below is related to all specification extensions, not just the fluent flavored specification extensions.
-1. If you have a test that for some reason has an assertion in the middle of some code.
public void MockAsExistingInterfaceAfterObjectSucceedsIfNotNew()
var mock = new Mock<IBag>();
mock.As<IFoo>().SetupGet(x => x.Value).Returns(25);
var fm = mock.As<IFoo>();
fm.Setup(f => f.Execute());
It's a little difficult to tell where the assertion is because you don't get the syntax highlighting help from the static class name "Assert".
However I don't think the reason above is anything to stop using the pattern for a couple of the following:
- How often do you have assertions in the middle of your code?
- If you are doing your tests right, it doesn't take long to scan the above code for the ".Should..." extension method.
-1. Daniel from the Moq project tweeted Scott Bellware about his spec unit projects SpecificationExtensions.cs
@bellware shouldn't specunit ShouldNotEqual/etc. return the actual object rather than the expected? To chain other calls http://is.gd/iJuB
@bellware and ShouldBeNull/NotBeNull could also return the object: obj.ShouldNotBeNull().ShouldEqual(...), right?
with Scott's response being...
@kzu no because that would contribute to crowding many observations into a single method
To that I say, True, if you are doing pure Context/Specification based unit testing. However most of us aren't actually doing it (maybe we should?) so why not allow the test to say
So for now... I'm going to continue to go with the Fluent Specification Extensions.