Our first Coding Archaeology evening was certainly an interesting exercise with some really detailed discussions going on during the evening. The aim of the evening was to try to understand how NSubstitute works, rather than how to actually use NSubstitute. Of course with only two hours we couldn't possibly hope to understand the whole framework, but it was quite surprising how much we did explore.
We started out with a fairly basic exploration, looking at how Substitute.For
(..) returns a Castle proxy object. This was simply done by stepping into one of the basic unit tests with the debugger to follow the code path.
We then looked at the SubstituteExtensions class which provides extension methods like Recieved(...) and Returns(..) for the framework. It was interesting to find out that the following statement:
_engine.Recieved().Rev();
would also validate when expressed like:
_engine.Recieved();
_engine.Rev();
After the break we decided to look at how NSubstitute deals with raising events. To do this we built a Car class to take an IEngine (part of the tests in NSubstitute) and wrote a test, as you might in the 'real world' which raised the IEngine Stopped event. We used NSubstitute to create a fake of IEngine and injected it into Car and then raised the Stopped event using:
_engine.Stopped += Raise.Event(...);
From there we dug (pun absolutely intended) into the call stack to work out how event raising was implemented.
In conclusion the choice of NSubstitute was both good and bad. On the good side was the opportunity to look through some beautiful and clean code. The flip side was that the structure of the code, Overenthusiastic OO, as
Dave Tchepak calls it, was probably a bit much to tackle at the same time. It would have also been really good to have had a more detailed look at the structure of the unit tests, but in the end there just wasn't time to look at it all. Maybe another time...
