One of the great things about ALT.NET is the variety of choices it affords.  However, this can also become an albatross around your neck when trying to choose a particular unit testing framework, mocking framework, IoC container, etc.  I mean, if you haven't tried most if not all of the choices, then you don't know what you're missing.  Of course you can read about the different options out there, but that's no substitute for trying them out for yourself.  Having said that, there's still a lot of utility in reading about them to exploit them to your advantage.  Thus, I recently moved out of my normal comfort-zone, (NUnit, Rhino.Mocks, Windsor Container) and tried some other technologies. 

What follows is a short description of my impression of a couple of Unit Testing frameworks that I've played with in the past couple of weeks.  Note that this is not intended to be an complete portrayal of each tool, but rather how I felt when attempting to use them.

NUnit

This is the old standby, but there's a 2.5 alpha that I hadn't tried.  I liked a lot of the changes that have gone into it, but found that too many things that I depend on for integrating with NUnit don't work with 2.5 yet.

XUnit

I like XUnit.  It's simple.  ALT.NET takes a bad rap for being hard to adopt, so one thing I try to emphasize is simplicity.  This is XUnit's strength.  If I were starting someone off in Unit Testing, I'd tell them to look at XUnit.  I have to admit that I do like the Constraint model in NUnit, however.  It just reads more naturally.  Also, pretty much everything works with NUnit, but not necessarily with XUnit (like TeamCity, currently).  So eventually, I went back to NUnit 2.4.8.  It worked fine with TestDriven.NET, however.

So the moral of the story is that software (including OSS) has momentum.  Once you get used to a certain way of development, it feels painful to switch, even if the other applications have some nice new features.

Conspicuously missing here is MbUnit, which I've tried in the past but again went back to NUnit eventually.  I'll have to try it out again soon.

As I've said before, my organization does an awful lot of SharePoint work.  Since button-pushing really isn't my thing, I've got only a few options when it comes to coding most SharePoint projects:

• Custom Workflow
• Custom Web Parts

I've started to duplicate this blog on our internal MOSS server, and there's something that I've missed about dasBlog that's not available in WSS or MOSS blogs - Tag Clouds.  That sounds like a good place to get my feet wet in Web Part development.  I know that there are already several web parts available that provide tag clouds for MOSS, but of course, they're "not invented here".  No, seriously, this is purely for my own educational purposes, so even if I do provide a solution to the general public, there's certainly no assumption that it would be any better than what's already available.  This project will let me explore several interesting technologies:

• Web Part development (of course)
• Code Access Security (CAS) in SharePoint
• STSDEV
• Microsoft Unity (though I'd rather play with StructureMap <sigh/>.)
• VSTS 2008 TFS Team Build
• any other random bits of new tech that catch my eye!

Well, not really.  From what I could tell the guys who were maintaining NCover and NCoverExplorer as OSS projects, have formed their own company, Gnoso.  Despite the title of this post, I’m not upset or anything.  I code for both fun and profit, why should I begrudge these guys their mortgage payment? 

Other OSS maintainers have also profited from their OSS efforts.  DotNetNukeCorporation & Interface21 (the folks behind Spring & Spring.NET) both offer support/consulting services for their respective OSS products.  The difference, however, is that both DotNetNuke and Spring.NET remain OSS, whereas NCover is now licensed software.  But it’s not like the price they’re charging is egregious – the Enterprise version is only $299, a drop in the bucket of any software development project.  And if that still causes you to choke, there’s the “Pro” version that’s only $149, not to mention that the older versions (< v 2.0) of NCover are still free.  So rock on Gnoso.  You’ll get my $299 sooner or later – as long as my boss or client lets me expense it!

Testing is about a lot of things.  One of the major things is confidence.  When you have good test coverage you can have the confidence to make changes (assuming that you run your tests after making your changes, which not everyone does).  Making changes to a production system is risky business and the importance of the staging environment is paramount.  This gives you the liberty to try out new technology, new functionality, and things that you would otherwise be afraid to attempt (or should be).  One should not let one's enthusiasm to impress overcome common sense and while performing rigorous testing is not glamorous it not only builds your own confidence, but other's confidence in you as well.  Shortcuts lead to not only grief but sometimes embarrassment as well.  Seeing green is such a good feeling.

CI Factory is another technology that I failed to put on my "to do" list. Nevertheless, I've been playing around with it this past week and from what I've seen so far, I really like it. I'm a little concerned that it could "kitchen sink" you to death, but on the whole, I think this is a great boon to someone trying to quickly bring up a continuous integration server. I still think it's better if you learn the basics of particularly CruiseControl.NET and NAnt yourself before bringing up a CI server. In fact, if you didn't at least have a basic understanding of these you wouldn't be able to troubleshoot any problems encountered along the way of bringing up CI Factory, nor would you be able to customize/extend it in any way. .NET Rocks! or more precisely dnr tv has what I would call the best screen cast so far explaining how to set up CI Factory. In about 1 hour Jay Flowers, Scott Hanselman, and Carl Franklin had the whole SubText open source project downloaded and incorporated into a brand-new CI Server, though I think Carl was kind of bored during the whole thing. Here are some of the "gotchas" (just actually things to be aware of) that I've discovered so far when installing CI Factory:

• Don't try to develop on your buildserver, certain packages in CI factory get confused
• Have Subversion installed (if you're using SVN) before you try to install CI Factory. Make sure you have it installed to C:\program files\subversion and that it's in your path
• Have NCover installed before you try to install CI Factory
• Go with the flow the first few times you attempt to install CI Factory. Don't try to customize it too much. Once you're familiar with how things work, then you can start to experiment.
• I was getting errors trying to commit a large amount of information to Google Code during CI Factory setup

I'm a little concerned about using something like Google Code or CodePlex (with SVNBridge) with CI Factory on a large project. I know Google Code limits your storage to 100MB (too bad they can't have storage more like Gmail) and with literally no code in my CI solution I was up to an exported source of 311 MB in no time, though the Subversion repository itself was only about 15 MB. It would probably be OK for a small project without a lot of change, however. Where CI Factory will really shine for me is during customer engagements, with bringing in VM and installing a CI server, even for a pre-existing application such as was done with SubText in just an hour or so. Kudos to Jay Flowers, who must dream in NAnt.

I've done a couple more experiments with a simple "Hello World" version of a Presenter First style app.

With the first one, I've gotten rid of the manual mock objects (less code to maintain) and replaced it with dynamic mock objects from Rhino Mocks. I do believe that Oren Eini has thought of everything when he made Rhino: source code here

And with the second one, I've utilized not only the dynamic mocks, but also Windsor Container for the Windows Forms app, and an auto-mocking container developed by the folks at Eleutian for the TDD test. I must say, however, that it was a little tricky getting the Presenter object in the right state for auto-mocking + testing. At first I couldn't "auto-mock" the Presenter object before I'd obtained the View mock. The Presenter constructor was setting up the event subscription to the view, but I couldn't get to the Auto-Mocked view until the Presenter constructor was already called, which messed up my mock recording/playback sequence. Therefore, I had to add an "Initialize" method to the Presenter object. Again, it's a little more code in the short run, but if this were an extensive application, there would be a heck of a lot less monotonous configuration code for all the dependency injection stuff. I love the fact that the Windows Forms app has absolutely no idea what objects are being created for its use. That's all up to the configuration file: source code here

I'm getting a strange error this morning… or lack thereof. I know for a fact that a specific Web Service is failing, yet my test which calls it is passing. Looking closer, I can see that I'm not even connected to the network that the web service resides on when running this test, so there's no way it should be passing. I'm getting a false-negative (a test that fails when it really should pass is a false-positive). Why is this happening? My first suspicion is the Visual Studio test-integration tool for NUnit, in this case it's ReSharper. I have heard some negative comments about using ReSharper for your unit testing, and this may be the reason why. So let's try the test in the NUnit GUI. Whoa. It passes in the NUnit GUI. Why is that? I could test from the command-line, but I suspect that I'd get the same result.

Let's look at the test itself. Maybe there is a false assumption there. Interesting – I see a nice comment that says "TODO: Revise Test". That's not very illuminating. I'm pretty sure I didn't write this test personally, either. A quick check of the test doesn't reveal anything to me, either. It should fail given the lack of a proper network connection. Now, I should probably write a new "failing" test to test for the lack of a network connection, but I don't want to lose my train of thought, so let's try plain vanilla NUnit from the command line. Weird, it passes there, too. It must be the test. Um… I'm stupid. The test is expecting an exception, so of course it passes. Gahh…. That would explain the need to revise the test in my cryptic TODO. Maybe whoever was reading the test would be astute enough to figure out that there was an "ExpectedException". But as it turns out, it was a lack of "intentionality" in the name of the test. The test is named "CreateUser_Test". To me that implies that the test should successfully create a user. In fact, it fails to do so, intentionally (or just as a kludge). It would be more rightly called "CreateUser_Exception" or somesuch.

You may think I've been slacking, but really I've been scouting out new free technology!  WatiN is a very useful tool for performing web application testing. http://watin.sourceforge.net/.  A necessary companion to WatiN is a free tool from Microsoft called the IE Developer Toolbar.  Why have I never used this before?!?!  Thanks to Justin Miller for pointing me toward WatiN!

And of course this is still in the screen-cast series, so you won't get away without the obligatory WatiN Screen Cast (24+ MB)

This is a short one since I'm short on time.  I did want to get something out however, so here it is.  Enjoy the NCover screencast

NUnit is my unit testing tool of choice. I remember a few years ago when I was trying to figure out all of this automated unit testing stuff and the problems I had learning without someone to show me how. I hope that this screencast can make the introduction to automated unit testing a little simpler and make testing in particular more prevalent with those who view it.

NUnit Basics