[As a note, I'd this post open since this morning, and contiously added more to it as time went by.]
I hate tricks. If you recall, I wondered about all those not implemented GetHashCode(), they were because EasyMock.Net override the Equals method in a class that represent method's arguments, and then put it in a dictionary. Part of the logic of verifying and validating that the mock passed is to query the dictionary for the existance of the arguments. I'm not explaining it very well, basically, they were doing things like this:
ResultList list = (ResultList) resultListMap[expected];
if (list.HasValidCallCount && !expected.Equals(actual))
What this does is to scan through the dictionary, comaring each argument set to the expected one. Further more, this is possible:
This is just wrong, and that was where it all started to break. I wanted to add constraints to the library, and for the life of me I couldn't fiigure out how it validated things. This is a properly designed application, full of patterns and well defined interfaces. This translate to hard to read if you don't have a clue about the code. (I only heard about it two days ago). Some of the method calls took 8 levels to reach the level they were doing something, all along adding context. It wasn't fun to discover how it worked. It is fun to work with it now that I know how it's working, though.
So I write a test to the functionality that I want, make my change, and run all the tests again. All the tests except mine passed. Finding out about this wasn't fun. This is a very nasty trick.
Nevertheless, the thought behind this library is amazing. The nasty piece of code above is limited to a single class. So it's pretty easy to change, once I figured out what was wrong. I currently managed (after three failed attempts [because I didn't understand fully what was going on] to add constraints to the library. Ironically, I'm currently using NMock's constraints, since building both the constraints and the constraint infrastructure was too much.
I just finished re-implementing NMock's constraints. Very easy to do. Demonstrate that a lot of tiny pieces can have incredible value, iff* you know what their environment is.
I just implmented yet another great feature, Callbacks. This means that you can register for a method, and you'll get called with the method arguments. This allows for very powerful validation** and behaviour during tests.
I'm going to dog food it tomorrow, by converting NQA to use it, and then I'll release it. I think that it turned out to be a pretty good tool in the end.
* This is not a typo
** And much abuse, incidently :-)