I have to say that when I thought I’d start doing this I’d find it difficult to stop writing, not the other way around. The recent excellent first post by a colleague of mine has spurred me into action, obviously I don’t want to be outdone! As it happens, I seem to have written a good few drafts that are in the process of being refined, so there is some (hopefully) quality technical post-age on the way soon!
In the meantime, I thought I’d take time to discuss the progress on moving EmailValidator into Open Source land.
The answer is slowly but surely.
The Subversion repository is created, a basic structure exists and the underpinnings of a build system are also in-place. I’ve also been grateful to receive an open-source license to Clover.NET that I’ve installed both with Visual Studio .NET and inside the NAnt script so that an HTML report is generated on each build.
I’ve started making the first steps on the road to a functional product, and am approaching it slightly differently to how I’ve approached controls in the past. My real aim for this project is to produce something of the highest quality possible, and to me, that means something that has 100% code-coverage from tests.
Now, whether that’s something that is achieveable by myself (and anyone else that contributes) remains to be seen. My exposure to attempting to test ASP.NET controls so far has essentially proved relatively fruitless – roadblocks were hit far too soon on the lifecycle. However, since some aspects of lifecycle are indeterminate and can be influenced by other controls in the tree, it’s something that is too important not to test. So, this project will also serve as a good purpose for trying to identify ways to successfully test ASP.NET controls.
My previous exposure to code coverage was limited to NCover, but this seemed somewhat problematic and the reports generated (in particular, the ones that were generated through various CruiseControl.NET XSLTs I’d come across) were very difficult to follow. The result was relying mainly on the overall percentage of coverage, without being able to drill-down to precisely whereabouts the problems were.
Clover.NET is different, not only is it very easy to plug-in, it works well and produces the best kind of reporting possible – directly in the IDE. This is something I believe will be incredibly beneficial once I get around to building the ASP.NET control side of the project. At present, code coverage serves as a good reminder that my ‘little baby’ TDD steps aren’t growing too big, or that I’m jumping ahead of the test when I implement. My green-bar/red-bar psychology has been instilled sofar as to make any red bar abhorrent and thus require immediate action. I like it. Time to see whether I can keep the solid green bar up! This is definitely something I’ll be charting my progress with here.
Which reminds me, I must get around to finding a way to automatically publish Clover.NET reports somewhere on here along with access to the SVN repository, time to get back to it!