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.

 

I'm not dissing MS Unity, Microsoft's new IoC Container - I'm really going to give it a chance.  Rather, I'm talking about the reaction to it on the Yahoo! [altdotnet] group.

I have just spent most of the morning following a thread on the [altdotnet] mailing list titled "Unity" Ioc from Microsoft has been released in CTP...  And it has.  But in retrospect, based on the thread, "Unity" was a very ironic name choice for the tool.  This is a very long thread that is involving dozens of folks.  It started off by comparing the functionality in Unity to functionality in other IoC containers, mostly Castle Windsor & StructureMap.  The Spring.NET crowd has been strangely silent.

Later in the thread, however, the "altdotnet"ness of the list has begun to show its colors. Passions have arisen and tempered.  Staunch defenders of each "side" (and there are more than two sides to this polygon) have held their ground while alternately being gracious one minute and on-the-attack the next.  It's the ultimate Reality TV... except that it's not TV, of course.

I've wasted too much time trying to follow this thread and I declare that I am DONE with it.  Not that the task wasn't worth it.  I've learned a lot about IoC that I hadn't know before.  I'm familiar with Windsor, and I've downloaded Unity and played around with it as well.  The really great gem that I have just discovered is StructureMap.  I just love the "fluent interface" it has - much like is available in Rhino.Mocks.  Fun, geeky stuff.

I thought it would be a useful exercise to compare "Hello, World!" scenarios between the big-four (and, yes, I'm including Unity as part of that):

Function	Castle Windsor	StructureMap	Unity	Spring.NET
Putting an interface and concrete type into the IoC container	WindsorContainer. AddComponent()	StructureMapConfiguration. BuildInstancesOf(). TheDefaultIsConcreteType()	UnityContainer. Register()	N/A - Spring doesn't support XMLless config (that I could find).  Those Java guys just have a love affair with XML, I guess
Getting a concrete type for a given interface	Resolve()	ObjectFactory. GetInstance()	UnityContainer. Get()
Default items are	Singleton	separate instance	separate instances

The fluent-interface of StructureMap is so nice.  Yes, it's longer to type, but hey, that's what IntelliSense is fore, and that will make it easier for new developers to discover.

Incidentally, Unity looks an awful lot like Windsor in its syntax, and it was mentioned in the aforementioned thread that the PM on the Unity project is a big Windsor fan.

Apology: I just couldn't resist the lolcats thing, it was just too apropos.  This is my one (1), lifetime, self-imposed limit.

 

A colleague, Daren May, has turned me onto a great Scrum resource, Scrum and XP from the Trenches, which is the best online Scrum resource that I've seen yet.  It's a free PDF book about one ScrumMaster's experience with Scrum.  Most of what I've read about Scrum so far has either been heavy on theory or very "Pie in the Sky"ish. I was so impressed by it that I've emailed everyone I know who's interested in Scrum.

The author, Henrik Kniberg, has a blog that's just dynamite as well.  Lots of good content on agile and Scrum in there.

As I said, I was very impressed, so much so that I decided to pay for a hard-bound copy, which is pretty out of character for me if it's available in a free form.

 

It doesn't look like Google Reader or FeedDemon are going to work out for subscribing to any of my secured corporate blogs (which currently only consist of my own blog).  Let's give the Windows Common Feed List a try.  Nope.  IE doesn't support "feeds with passwords" as it puts it.  Let's try Outlook.  It looks like Outlook is the only reader (that I know of so far) that handles this kind of feed.  Wow.  I didn't know Outlook had it in it.  Am I ready to leave Google Reader yet?  Mmm... not really, but I'll just have to have separate areas for public and private feeds from now on, however.

 

Wow, where have I been?  I've taken leaves of absence before, but it seems that I've fallen into "Oblivion."  Oblivion sure is fun, but it's also a complete time-waster.  I need a game that engages me for one hour at a time, about once a week or so.  Oblivion was not that game, it's kind of all-engrossing for me.

But this isn't about Oblivion - it's about security.  A LONG time ago I promised a part 2 to a security blog on passwords, etc.  Now that we know how to choose a good password, it's time to store it somewhere, or them rather.  We don't use the same password everywhere so it may be difficult to remember each and every password, so we need to store our passwords somewhere securely.  Here is what I do (though in revealing this I will expose myself to a miniscule amount of risk by detailing it here - more on that later). 

As far as where to store passwords, I really like TiddlyWiki.  There for awhile it was a close race between OneNote and TiddlyWiki as to what would be my general note-taking tool, but OneNote finally won out since I can use it (kind of) on my Windows Mobile device, and I can't use TiddlyWiki on it.  However, TiddlyWiki wins out on the desktop since I don't have to have anything but a browser. 

I was kind of confused at first about TiddlyWiki - I thought a wiki required a server, but not TiddlyWiki.  It's completely self-contained on a client PC, implemented in JavaScript (amazing, I think).  If you want to learn your JavaScript better, that would be the code to look at.

So TiddlyWiki is a great note-taking/organizing tool, but what about SECURITY?  Enter TrueCrypt.  With TrueCrypt I can create a secure file that acts as a virtual drive, completely encrypted with the absolute latest and strongest encryption available - you can even use multiple encryption algorithms at the same time, but it may be overkill outside the Department of Defense or in large multi-national organizations. Anyway, I place my TiddlyWiki file in a small TrueCrypt partition, and coupled with either FolderShare or Groove you can have your secured passwords anywhere, anytime.

By the way, what pulled me out of Oblivion?  It's Christmas at the in-laws, with the game only on my desktop about three hundred miles away.  [Back home now, and I just gave my wife the DVD and told her to hide it.]

I'm also not posting this entry right away, since my in-laws only have dial-up and about twelve people are all vying for the same 24k baud line.  No cable here in this part of rural West Virginia.  Definitely no DSL.  Satellite would be about the only option, and my mother in-law spam-forward's enough email over dial-up just fine.  I'd hate to see what would happen if they got broadband.  (Just kidding, Barbara.  I'm really happy you took me off of your auto-forward list years ago).  Ironically, for this post, I don't really have access to my passwords out here, but since I don't have Internet access it doesn't matter!

I doubt she'll ever read this anyway.  This blog is pretty narrowly targeted to a particular audience.  When any of my family sees my blog listed in my email signature they visit it... once.  Apparently they have no idea what I'm talking about, though I hope that the past couple are just a tad more general interest than my usual fare.

 

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

 

 

 

Apparently I'm just dangerous enough to really screw things up in a blog that I have absolute control over.  Thus my old "Community Server 2.1" blog is toast.  Since I'm supposed to be learning WSS 3.0 anyway, I thought this was a good opportunity to start a little "dogfooding".

 

 

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