Continuous Disintegration

I’ve read a few posts   about   Kobe , a new sample ASP.NET MVC application intended to provide guidance for web application development. One thing that really jumps out at me (taking the bloggers at their word) as a glaring mistake is the absence of any unit tests. I mean, isn't testing one of the driving factors for the creation of ASP.NET MVC (second bullet point)?

I got bitten by not knowing some Rhino Mocks API details today. I had some tests written a certain way which were passing and some others written the same way which were failing. (Code can be found here .) In the case of the successful tests, Rhino Mocks appeared to be properly returning a mock object when a property was called on another mock, and in the case of the failing tests it was returning nulls for the property on a mocked object. There didn’t appear to be any difference in the way I needed to declare and setup the mocks used in the test, but there was a subtle one: the code that passed the tests only accessed the property once , whereas the code that failed accessed it multiple times . Because of the way I set up my mocks, a mock was returned for the property the first time it was accessed only. If you use Expect.Call(…).Return(someObject) , by default the method/property will only return the specified object once . If you use a stub or SetupResult.For(…).Return(someObject)

UPDATE: As I suspected, this functionality was right in front of my face – it’s called PredicateConstraint in Rhino Mocks. I also realize that I managed to completely ignore the existence of Predicate<T> in the framework, and write my own predicate delegate. Hey, I was on a roll. Rhino Mocks has a PropertyConstraint class that allows you to check the values on properties of objects passed into the method as part of the verification for that method being called. Unfortunately, the name of the property is specified as a string, which means the benefits of strong-typing that Rhino Mocks is normally so good at preserving are lost. Here’s an example (using Rhino Mocks 3.3 and .NET 2.0): [Test] public void Main_Form_Should_Show_Start_Panel_On_Load() { MockRepository mockRepository = new MockRepository(); IMainFormView mockView = mockRepository.DynamicMock<IMainFormView>(); IEventRaiser loadEventRaiser = GetEventRaiserFor(delegate { mockView.Load += null; });

Sooo... long time, no post! All zero readers of this blog might be curious about why I disappeared. The short story is I’ve been sidetracked by personal issues combined with a butt-ton (sorry to those in far away lands; I don’t know how to convert this to metric) of work at my paying gig. We’ve all been there and done that. I’m sure you can relate, non-existent reader. But I’m not making any more excuses! This post serves as a list of topics I want to cover in future posts. It’s long, so I doubt I’ll get to all of these. More ‘SharpMock’ – I haven’t abandoned this project, but I was saddened when I realized I had forgotten all I learned about PostSharp when I cracked open the [smelly from having gone so long without bathing] spike code. Creating DSLs with MGrammar – I’ve noticed a lot of bloggers are unsure about the vision Microsoft has for ‘Oslo’. Count me among them. But I definitely have had some fun playing around with Intellipad and MGrammar recently. I see a lot of pot