I have been merrilly using NCrunch – an “automated concurrent testing tool for Visual Studio” – for almost three years now. I ponied up for a paid license when it made the transition from beta to RTM, and I recently shelled out again for an upgrade to version 2. Why?! Why do this when plenty of test runners are free, or bundled with software I already own such as ReSharper and Visual Studio itself? ...
This dumb mistake just cost me an hour spelunking around in the debugger: var status = source.Substring(source.LastIndexOf("/" + 1)); (where source is e.g. “http://foo.com/status/all-is-good“) Fortunately the ramifications were picked up in the acceptance tests, but the root cause wasn’t at all obvious from such a high level. Lesson for the day – code is never too trivial to warrant unit testing.
When I first started writing automated unit tests for my code, I remember getting carried away writing lots of tiny little tests, each with a single Assert. It felt good initially to see all those green ticks, but rapidly became a maintenance headache, and I am now happier having fewer less-brittle tests that do more. I think it’s great when tools like AutoMapper provide powerful methods like… …allowing me to test large swathes of the system configuration with a single, stable test. ...
I’ve been asked “How do you test LINQ queries?” a couple of times in the past few months, so I thought I’d blog my answer for the benefit of all you lovely people. Firstly I should explain how I’ve been doing most of my data access in recent months. I find that the Repository pattern, and particularly the .NET implementation described here by Fabio Maulo meets the vast majority of requirements I have in my applications, and I fall back on additionally using custom DAOs when required. ...
On my continuing journey through this thrilling world of professional software development, I frequently encounter teams who hold no truck with this crazy new-fangled concept of unit testing. Heck, truth be told, I sometimes come across teams who don’t use source control, but that’s by the bye. In these situations, I try my best to lead by example, continuing to practise TDD on any new code that I cut, and insisting on covering with unit tests any pre-existing code which I have to modify. Sooner or later, this prompts someone to ask why I am doing this (often insinuating that I am wasting my time, and by implication the client’s money). At that point, flustered, I invariably struggle to remember or adequately articulate the many and various ways in which unit testing makes me a better developer. So, consider this blog post a personal aide-mémoire to help me the next time this occurs (as well as being a homage to Jake Shillingford’s second-best song). ...
Up at 0500 yesterday and onto the early GNER Mallard down to that London town for the MSDN briefing on eXtreme programming with .NET. It was pleasant not to be driving for a change, and speeding through the Yorkshire countryside early on a midsummer morning was very relaxing – what a stark contrast with the hot crowded tube that I had to catch on arrival to the big smoke. Three stops down to Oxford Circus seemed to last as long as the entire preceeding train journey. How people do this every single day I do not know.. ...