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.

The type name that you need to use in config files, such as for IoC containers, can be quite complex. For me, it's easier just to spike them than to try to remember the format gobbledy-gook.

public class GenericsTypeSpikes
{
    [Fact]
    public void The_name_of_a_complex_type_can_be_found_in_Type_AssemblyQualifiedName()
    {
        Type t = typeof(IList<ISource>);

        Assert.Equal("System.Collections.Generic.IList`1[[Blah.Core.ISource, Blah.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]], mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089", t.AssemblyQualifiedName);
    }
}

Active Directory is funny.

Or should I say "permissions in Active Directory are funny."

I find that whenever I'm "stuck" on a problem for a good chunk of the day (AD or not) , about 80% of the time it's a permissions issue.  A couple of days ago I was stuck on an issue that I knew was a permissions issue, but I couldn't figure out why.  I mean, here I was, supposedly something of an development expert in directory services, but I couldn't get my DirectoryServices code to delete a simple AD object.  I could create objects, but I couldn't delete them.

Now, at this particular client they've tightened down the screws in their environment substantially, so simply increasing my permissions willy-nilly was out of the question.  No domain admin privileges here.  I'm not even sure any of the developers on this project even use Active Directory Users & Computers, they seem to only use home-grown LDAP tools for examining AD.  They are able to delete items with one particular home-grown tool, but it was written in VB - in all it's COM, late-binding, who-knows-what's-really-lurking-under-this-IUnknown-interface glory.

Has anyone ever tried to peer into the ObjectSecurity class?  It's not for the faint of heart.  And it wasn't something that I was going to be able to decipher in an afternoon.  So I downloaded the old Windows 2003 admin pack, installed it on my XP development box, and went into all the gory details that are AD ACLs.

The question was, why could the old VB code delete the object when my DirectoryServices code not do it?  According to AD Users & Computers, the credentials I was using did not have "delete" permission on the object.  I knew that.  That's what "access denied" usually means.  How could I explain this to the fellow who was successfully deleting with the VB code and expected me to do the same?  DirectoryEntry.DeleteTree() simply would not work. 

However, upon further examination, I could see that the OU that I was dealing with did allow my credentials to create and delete child objects.  Hmm...  One more quick test confirmed it.  Although DirectoryEntry.DeleteTree() failed, with the OU I could do DirectoryEntry.Children.Remove(objectInQuestion).  That's just crazy.  Boggles the mind.  But it works.

Of course, if the AD admins want to save another developer further grief (and there's no reason to believe they would - I know some sadistic infrastructure folks), then they'll just add the delete permission and avoid further confusion.

It's incredible how fast things can change if you turn off your developer technology radar for a few months.  I was pretty comfortable with my knowledge of what was out there around fall of '07.  I'd explored pretty much all the different tools and technologies that had tickled my fancy and even though I wasn't an expert in all of them, I knew that I could pick any one of them up pretty quickly if need be.  So down went my radar for awhile.

Holy cow.

Apparently not everyone has been as idle as I have been.  Here is a list that I compiled in a single afternoon of some things (I'm sure there are plenty more) that I'd like to try out in the not-too-distant-future to see if they can assist me in my daily chores.  What follows is not anything near a full review (basically I've pretty much only heard of them at this point), so my descriptions of what they are may be WAY off:

How about you?  What kind of technologies have you excited right now?

STSDEV is a code generation tool on CodePlex for SharePoint, kind of like my PoShGen, except much more polished.  It generates a starting project for several different kinds of scenarios - SharePoint Solutions, Features, & Web Parts.  I tried to bring it up on a box with Visual Studio 2008, however, and the app crashed.  It was trying to use the Microsoft.Build.BuildEngine.Engine object and fails.  I noticed that MsBuild.exe seems to work fine, so I posted a patch on CodePlex that replaces the routine that attempts to build the project with code that shells out to console (it's already a console app, so it uses the same window).  With that it works fine in 2008 and should work fine for VS2005, too.

You can get the patch for STSDEV here.

Wow, that was a lot of work.  I always hate when a screencast of demo starts with this big huge installation of a bunch of different technologies, but doesn't tell you how to get the same environment, so I started from scratch and show you how to go from a generic W2K3 base image to a fully functional TFS 2008 box and THEN show the Continuous Integration sample.  Due to the fact that we're going soup to nuts it's a pretty big screencast for me 34+ minutes - a new record for me.  I only wish complete installations like this REALLY only took 30-40 minutes.

Screencast: Continuous Integration and TFS 2008

My current project has me working on an Outlook 2003 Add-In (funny how clients aren't always up with the latest-and-greatest, huh?).  With it, I should be able to do just about anything in Outlook... if I only knew how.  The problem is that this project has a really short duration (2 wks.) and I've got to figure out how to do some things that I've never done before.  Usually I can find out all I need to know after a few sessions with Google, but info on Outlook Add-Ins (beyond the simple "Hello, World" style, which I can already do - there's a wizard, for heaven's sake) is pretty rare.  Most searches bring back references to Sue Mosher's Outlook books, but after looking at the contents, there's nothing in there about Add-Ins so far as I can tell.  The one book specifically about VSTO Add-Ins doesn't have any Outlook examples that I could find.  Sheesh.  I'm still installing VS 2008 on a box that has Office 2003 installed, which was another pain.  I tossed my copy of Office 2003 awhile back and had to go the the company software download area to get a copy.  So once 2008 is installed, with both support for Outlook 2003 & 2007, I'm hoping that they have some stellar documentation.

Anyone have any great tips for Outlook Add-In development?

I'm beginning to feel like Ayende @ Rahien with all my posts today.

I'm slowly coming to the realization that one of my favorite patterns, namely Presenter-First, just won't work well in the new ASP.NET MVC Framework.  Perhaps I should have expected trouble (and maybe I did just a little), since the MVC (Model-View-Controller) pattern is the antecedent of MVP (Model-View-Presenter) pattern.

In fact, Presenter-First may actually work better in the old ASP.NET WebForms than it does in MVC, though in a slightly kludgy way.  This is due to the fact that at least in WebForms events are supported through the "postback" mechanism, whereas the MVC Framework does not support postbacks (nor events from what I can tell).  Presenter-First  relies on events to connect the Presenter to both the View and the Model, and... well... there just is no capability for events from the View to the Presenter/Controller. 

Presenter-First simply acts as glue, abstracting the interface between the Model and the View.  The Model knows nothing of the View, and the View knows nothing of the Model, and neither cares.

Another point at which MVC collides with Presenter First is in the concept of an "MVP Triad" in Presenter-First.  The Triad is a logical connection between a specific Model, View, and Presenter.  The Presenter is more or less associated with a single view from what I've been able to tell, but in the MVC Framework, a controller (presenter) is capable of rendering many views.  Oy vey.  Things just get worse.

I still think I like the idea that the Presenter/Controller is as thin as possible, and that the View is even thinner (if possible).  The Model should handle all the grunt-work, as I advocate a Model which is more of an "application model" rather than a "data model." 

No matter how you go about it, you're going to lose the cool capability to use the same Model between both a web-based client and a smart client like WinForms or WPF.

Another problem that I see with the plain vanilla MVC is that you still have that old code-behind class (the web-pages are still .ASPX files after all, just without view state or postback), and it is ever so easy to stuff functionality in there where it does not belong in the code-behind.  Put your custom code in the application model, not in your view, and to a lesser extent not in your controller.  I do realize, however, that it is possible to forget WebForms altogether in the MVC Framework and to roll-your-own view engine or use one from Monorail.

Now, if I can just figure out how AJAX works with the MVC pattern... hmm.

I'm currently "in-between" projects here at the EMC Microsoft Practice, and partially through guilt that I'm not "producing" anything right now, I'm going to use this blog to assuage my guilt, somewhat.  I'll be using it (for the time-being) as what "blogs" were originally meant for, more or less.  That is, a diary of "stuff I do".  I'll try to continue to make it interesting, but it probably won't be as in-depth and as focused as in the past.  No, I'm not going to Twitter, since you don't need to know how many diapers I change a day (plenty today, let me tell you), etc., but I'll talk about each thing I work on for as long as my Attention Deficit Disorder allows.

Today I began by downloading code and watching/listening to some screen casts coming out of Microsoft for ASP.NET, namely the ASP.NET 3.5 "Extensions", which are really more like ASP.NET 3.6.  Pretty much the only thing I was originally interested in was the ASP.NET MVC Framework, which helps make TDD for web-sites easier to do, and that is always cool.  But there are other interesting things in these extensions as well, like "Dynamic Data", which appears to bring the Web to a point where VB6 was years and years ago, Point to some tables and "voila!", you've got a completely workable solution for instant CRUD.

I almost forgot, I have to do a phone-screen today.  In the past I've used the FizzBuzz test via Live Meeting, but I should probably come up with something a little more original.  How about:

Write a method for a console application that:

Performs a loop that goes from 3 - 99 by threes, prints the current time when the index is divisible by 4 and prints yesterday's date/time when the index ends in the digit 7.

That's a little harder (but only slightly) than Fizz Buzz, but still lets you gauge a candidate's basic coding ability, which is really all it needs to do.  The point isn't that there's one BEST solution, but rather it's illuminating to watch a simple problem like this be solved on the spot.  What if someone reads my blog and figures it out beforehand?  Well, if you read my blog, then you gotta be pretty good anyway, right?  You're hired!  How did it go?  You guys aren't the HR department, so I'm not gonna tell.

I've just spent more time than I'd like to admit finding a decent tool with which to write to my blog.  Back when I was using WSS 3.0 as my "blog engine" I used Word 2007 as my blog entry tool, but I've discovered today that it doesn't work so hot with dasBlog.  With dasBlog, I'd been either using the built-in web-based blogging functionality to dasBlog or BlogJet.  The trial for BlogJet has expired and I just can't bring myself to fork over about $47 US for the thing.  I just didn't get enough bang for that amount of buck.  So I'm back to using another free tool, "Windows Live Writer," which so far seems to work like a breeze, even with dasBlog.

Well, that's pretty much been my day today so far (after 5:30 PM here). Not that it's over. I'll probably be sitting here doing more or less the same thing until about bed time - or past.

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!

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

Last night's "Birds of a Feather" Session on "Creating Flexible Software: TDD, Mocking, and Dependency Injection" was the best session yet here at Tech Ed 2007. Some of the best minds using Microsoft technologies were on hand to hear James Kovacs (http://jameskovacs.com/) lead the discussion on all of the above. There were several skeptics in the audience who questioned the viability of not only mock objects, but also unit testing in general. Really understanding the "Separation of Concerns" argument is pretty much all anyone needs to understand in order to "see the light"… I'm still searching for a good Separation of Concerns article on the web for a needed link. Anyway, using Mocks, you can achieve a good SOC model. Now, I don't know if there were any that were converted last night, but I could tell that some definitely wanted to believe that such techniques could help them build better software.

I look forward in the near future to start applying these principles to my current and future projects.

I'm sitting in my first Tech Ed breakout session.  It's titled "Ron Jacobs on the Architecture Landscape".  If you don't know Ron Jacobs, he's a member of member of the Microsoft Architecture Evangelism team.  The title was pretty vague, but since I listen to ARCast (http://channel9.msdn.com/shows/ARCast.TV) I decided to attend.  So far (and we're only about 1/2-way through) he's discussed TDD, MVC, MVP, NMock, RhinoMock, and even the "Humble Dialog"!

 He's really doing a great job.  It may be more information than those without at least a basic understanding or agile development can absorb.  I'm even learning some things!  I just learned that the way I'm naming my Humble Dialog views methods/properties is wrong.  I'm going to listen more now.

Later…

The talk is long over now, and the "content" here at Tech Ed regarding Agile development methodologies is significant and deep. Not once from any of the presenters have I heard the words "generating tests" and that's good news. In Ron's talk, he had a video segment featuring Peter Provost. Peter seems to be the "Tour de Force" for some agile principals and practices at Microsoft. I got a chance to talk to both Peter and Ron after their talk down at the Architecture booth in the "blue" area at Tech Ed (the yellow, green and blue areas are where mostly MS folks hang out to chat about their "stuff"). It's great interaction with the "blue shirts" (Microsoft staff) and they're eager to talk. The thing that I found significant was that it seems that a lot (if not most) of the talk around the Architecture blue shirts is around Agile. Now, I'm sure there are plenty of SOA talks going on as well, but I can almost fill my schedule with agile stuff around here.

Anyways, I asked both Peter and Ron what their experience was within Microsoft regarding the spreading of Agile practices. It sounds like Peter is telling anyone who will listen about the TDD gospel. And that's great – I hope people listen.