Fear and Loathing

In my never ending quest for the holy grail I continue to ask more questions than I answer. Recently as I was putting together our unit tests for a project, I decided to give the ObjectMother pattern a whirl. This is a pattern dreamed up by some ThoughtWorkers and is a simple, scalable framework whose sole purpose is to construct and facilitate the customization of test objects. ObjectMother manages the lifecycle of test objects including creation, customization and, when necessary, deletion. I think it's an interesting pattern but is there a real advantage to using it over just creating and initializing objects in your test [Setup].

Lets say your have a Task class in your Domain that manages tasks for users. Here's our Task class:

public class Task

{

      private string name = string.Empty;

      private string owner = string.Empty;

      private DateTime dueDate = DateTime.Now.AddDays(7);

      private DateTime notificationDate = DateTime.Now;

      public Task()

      {

      }

      public string Name

      {

            get { return name; }

            set { name = value; }

      }

      public string Owner

      {

            get { return owner; }

            set { owner = value; }

      }

      public DateTime DueDate

      {

            get { return dueDate; }

            set { dueDate = value; }

      }

      public DateTime NotificationDate

      {

            get { return notificationDate; }

            set { notificationDate = value; }

      }

}

There are some requirements the business tells us that we want to test against.

• The due date must be greater than the notification date
• A task must be assigned to someone
• A task must have a name

This leads us to building some tests that look something like this:

[TestFixture]

public class TaskTests

{

      [SetUp]

      public void SetUp()

      {

      }

      [TearDown]

      public void TearDown()

      {

      }

      [Test]

      public void TaskCreation()

      {

            Task task = new Task();

            task.Name = "Release Windows under the GPL";

            task.Owner = "Bill Gates";

            task.DueDate = DateTime.Parse("12/31/2009");

            task.NotificationDate = DateTime.Parse("01/01/2010");

            Assert.AreEqual(task.Name, string.Empty);

            Assert.AreEqual(task.Owner, string.Empty);

            Assert.IsNull(task.NotificationDate);

            Assert.IsNull(task.DueDate);

      }

      [Test]

      public void DueDateAfterNotificationDate()

      {

            Task task = new Task();

            task.DueDate = DateTime.Now.AddDays(1);

            task.NotificationDate = DateTime.Now;

            Assert.IsTrue(task.DueDate > task.NotificationDate, "Due date must be after notification date.");              

      }

      [Test]

      public void DueDateBeforeNotificationDate()

      {

            Task task = new Task();

            task.DueDate = DateTime.Now.AddDays(-1);

            task.NotificationDate = DateTime.Now;

            Assert.IsTrue(task.DueDate < task.NotificationDate, "Due date cannot be before notification date.");              

      }

}

Using the ObjectMother pattern, I can initialize my task object with the appropriate values using static creators like so:

public class ObjectMother

{

      public ObjectMother()

      {

      }

      public static Task CreateTask()

      {

            Task task = new Task();

            task.Name = "Release Windows under the GPL";

            task.Owner = "Bill Gates";

            task.DueDate = DateTime.Parse("12/31/2009");

            task.NotificationDate = DateTime.Parse("01/01/2010");

            return task;

      }

}

And I modify my tests to check against values from the ObjectMother like so:

[Test]

public void TaskCreation()

{

      Task task = ObjectMother.CreateTask();

      Assert.AreEqual(task.Name, string.Empty);

      Assert.AreEqual(task.Owner, string.Empty);

      Assert.IsNull(task.NotificationDate);

      Assert.IsNull(task.DueDate);

}

The traditional way of initializing my task object would be in the [Setup] method in my test class (using a private field called task of type Task) and initializing the values to some constant in my test. Alternately to the ObjectMother method above, I could create static fields in the ObjectMother the same way for comparision (or pass in values from the Test to the ObjectMother.CreateTask method to initialize them to known values). Here's the setup for my test in my [TestFixture]:

private Task task;

private string defaultTaskName = "Release Windows under the GPL";

private string defaultTaskOwner = "Bill Gates";

private DateTime defaultTaskDueDate = DateTime.Parse("01/01/2010");

private DateTime defaultTaskNotificationDate = DateTime.Parse("12/31/2009");

[SetUp]

public void SetUp()

{

      task = new Task();

      task.Name = defaultTaskName;

      task.Owner = defaultTaskOwner;

      task.DueDate = defaultTaskDueDate;

      task.NotificationDate = defaultTaskNotificationDate;

}

And my test would compare values to private fields of the test class which makes the creation test look something like this:

[Test]

public void TaskCreation()

{

      Assert.AreEqual(task.Name, defaultTaskName);

      Assert.AreEqual(task.Owner, defaultTaskOwner);

      Assert.IsNull(task.NotificationDate);

      Assert.IsNull(task.DueDate);

}

So where is the advantage to using an ObjectMother? Rather than comparing values against the private fields in my TestFixture I could compare them against static fields in the ObjectMother class. Maybe the ObjectMother is for more complicated objects that need lifecycle management but then do I really want to mix object creation in my tests?

More importantly, should I really compare a DateTime value to a DateTime value? Is that a valid test or am I testing the assignment of variables in the .NET framework. True, if you put logic into the Task class setter for DueDate and NotificationDate you can throw an exception so it doesn't allow invalid dates which would give me a more valid test. How many times have you seen this test:

[Test]

public void TestValidOwner()

{

      task.Owner = "John Smith";

      Assert.AreEqual(task.Owner,  "John Smith", "Task Owner does not match");

}

I've just seen too many samples claiming that it's a valid test when all they're doing is comparing a string to a string (alternately getting the string from a const value in the test class instead). How much value does this test add to your system?

Maybe I'm getting senile in my old(er) age. Maybe I'm just emotionally upset that my blog isn't listed on the usual ones for SharePoint. Maybe I'm just angry at the world. Anyways, I have to wonder about Web Parts and what is out there. Walk with me on this one. I look around and see lots of people writing new Web Parts which is great. But then I have to wonder is it really that great? Let's look at the classification of Web Parts that seem to be prevelant out there.

Roll-ups
These are things that rollup information from the current site. This can be documents on a site, list items (rolled up and presented into a chart), or a list of sub sites under a parent to create a dynamic site map. CorasWorks has this nailed down pat with their suites of tools (even allowing you to create your own rollup no matter what or where the content is). There are lots of others that do pretty much the same (both free and commercial).

RSS
So many feeders and consumers we have a plethora of choices in this area.

Display User
I don't know how many times I see the "How do I show the user his name" Web Part. The variation on this is to display all users (much like the Members Web Part) pulling information from AD, another site, a list, etc.

Document Management
Lets face it. Some of the document features of a doclib are pretty sad (like the inability to simply move a doclib from one place to another without enabling Explorer View that I can't stand). I've seen a few Web Parts including a recent one that presents a different view of a document library (a more Explorer like interface with a treeview and the details).

Recent Updates
A Web Part that shows what's been going on like documents posted in the last x days, lists updated, who visited, etc.

Navigation
Similar to the document management problem (and somewhat tied into the Rollups) is navigation. People seem to want different navigation so there are gobs of treeviews out there that show sites and subsites in every which way you can. This includes some other type of vertical navigation across an entire site like breadcrumbs and tabs.

Search Enhancements
A few of these have come out recently (including free ones from commercial vendors) basically enhancing the somewhat simple full-text search of WSS.

Did I miss anything? Probably. There are others out there. The point here is there really substance. The top 5 components on Microsofts Component Directory? A training kit that Microsoft created, 2 Web Parts that are bundled in with Office downloads, an RSS feeder, and an admin tool. What is it that people want besides what is already out there because frankly, these things listed are pretty standard fare. Is the SharePoint Web Part space that barren already? Where is that "killer" Web Part we've all been waiting for?

Or maybe the Web Part ideas are exhausted and what we really need are templates that cater to delivering complete solutions. Jim Duncan provided this through an experiment he did on building a blog site using WSS which looks awesome. Serge van den Oever (got your name right this time) also put together an enhanced dicussion list (still nothing as close to what I consider a discussion forum like phpBB, but great none the less). So maybe more list and site templates are what the community needs and not Web Parts? How about a Knowledge Base site template you can drop in and customize to your corporate needs. Or a Help Centre system complete with automated emails and ticket management. Not impossible to do and these templates can be built to adapt to anyones configuration if done correctly. Some of these solutions might contain custom Web Parts (like Jim's does) but again those are specialized for a specific purpose and not something anyone can use on any old Team site.

The Web Part framework was designed to provide a well crafted and simple system where you could plug anything (yes, anything) into a Web Part Page and benefit from it. Are the only Web Parts worth building the ones that solve a very specific business need like pulling SAP data from a backend system or talking to your corporate database systems? Is there nothing that is general enough that everyone wants, needs, desires that a Web Part could provide for you? I have yet to see the burning conversations in the newsgroups on "If only I had a Web Part that did...". Wouldn't that make people leap up and start building it (I know I sure would). It just isn't happening. So has the Web Part outlived it's glamour and the honeymoon is over already?

In my ongoing attempt to try to leverage the 2005 tools with our SharePoint development I continue to make some headway (not much though). I'll probably have to shelve my ideas for awhile as it's getting more and more painful everytime I try to model something. I mean, all of our code is just .NET classes. The UI is represented by Web Parts but the designers are having a hard time understanding these concepts. The problem is twofold with the 2005 tools. First it doesn't recognize somethine like SharePoint where there's an application layer, Web Services, Web Parts, a set of .NET classes to access the system (the SharePoint object model), and a database behind the whole thing. Second is that it's hard to just represent a plain jane .NET assembly as a tier in your application architecture.

In UML it's easy to put together a component called "Business Logic" then associate a few groups of classes (Domain Objects, DTOs, Services, Gateways, Mappers, etc.) with the component. That would all get deployed to a SharePoint server (or several of them) in a deplooyment diagram. In the Application designer I can only represent things for Web Services, Windows Applications, or Web Applications. Maybe I'm trying to drill down too deep but is it much to ask for a component that represents my Business Logic other than a "GenericApplication"?

On the plus side, it does understand Web Services so I've created a template that represents all the SharePoint Web Services (both Portal and WSS) which I can reuse. It did a great job of creating a definition of the Web Service and it's handy as a re-usable component, of course we don't use Web Services to get the job done as we have to talk to the object model directly. I've started building my own DSL templates for the Application and Logical Data Center designers that work with my SharePoint setups (even going so far to try to get the deployment part started but there are other challenges with that). I'm sure Microsoft will come along and provide these themselves some day so mine are just throw away at this point, but at least it's starting to look and feel like SharePoint (even if I can't deploy a 2.0 solution to SharePoint until at least 2006).

I'll see if I can get some pictures up of what I've done so far and where the challenges are. Of course give yourself at least a day to install, uninstall, and re-install your tools if you're moving from Beta 1 to the Technical Refresh. Even on a beast of a machine that I have for this (Xeon 3Ghz) its taking forever.

Okay, I give up. Sure this might be minor to some but it's bugging the heck our of me this fine morning. 

FxCop is a great tool. Sure, there are sometimes a few too many warning messages that it yells at you with and sometimes it suggests stupid things but for the most part it's yet another good tool to use to give your assemblies a sanity check. I ran one of our systems through FxCop to see what would come up, if there was anything we majorly missed and if there was something we should go back and refactor.

FxCop is just plain retarted when it comes to the Data Transfer Object pattern. We have a folder in our domain called DTO that appropriately holds any Data Tranfer Objects we create. Of course a folder in a .NET project creates a new namespace but that's fine. So we have our namespace called AppName.DTO (it's not AppName but you get the idea) and there are several DTO classes in there for a Project, a Task, etc. Naturally we named these ProjectDto, TaskDto, etc.

So first FxCop didn't like the namespace AppName.DTO and complained with the LongAcryonymsShouldBePascalCased error. Fair enough. So that means we should renamed the namespace to AppName.Dto to make it stop complaining. However right afterwards it complained with the IdentifiersShouldBeSpelledCorrectly when it hit our ProjectDto class, moaning that it didn't recognize the token 'Dto' in the class name.

So which is right?

1. AppName.Dto.ProjectDto
2. AppName.Dto.ProjectDTO
3. AppName.DTO.ProjectDto
4. AppName.DTO.ProjectDTO

I can't seem to find a combination that FxCop won't complain one way or another between the namespace and class names.

Update: Thanks to Joe for the clarification. It's not really FxCop that's braindead about Data Transfer Objects, it's the guy creating them (yeah, that would be me).

I'm currently trying to document (via reverse engineering and a some manual efforts) a .NET application built on top of SharePoint using Whitehorse. Whitehorse is the codename for the Visual Studio 2005 SOA tools (or maybe it's the codename for all of the new graphical designers in VS2005 I can never get that straight). Anyways, we have a SharePoint solution that is made up of a gaggle of Web Parts, a domain and various service and utility classes. Rather than using the normal UML markup for documenting our architecture (which I've already started) I wanted to give VS2005 a run for it's money and see how easy (or hard) it's going to be to move toward this. UML is nice and works but being a Microsoft shop, we're moving towards the DSL approach where the model is the system and away from the UML documentation model where it's just a pretty picture but not reality. My end goal here is that if I document the current (ASP 1.1/SharePoint) system now and it (somewhat) reflects reality then moving to a 2.0 based system where the model is <strong>real</strong> and not just a disconnected set of bits, I get a model of a system that works to show what the migration path will be like. It would make it easier if I took a regular ASP.NET app to do this, but I figured let's really challenge the system (even though VS2005 won't be out til later this year and SharePoint won't support .NET 2.0 until at least 2006).

Anyways, using drag and drop it's easy to lay out a system with the new tools. You drag an ExternalDatabase onto the model and specify the connection, etc. This is all great as you can use the items from the toolbox. Only problem is that there's nothing I can use to represent a SharePoint site or system because it's a bit of a hybrid. It's UI <strong>and</strong> a data access component. There's a nice little wiget to drag a BizTalkWebService on the system (or just a regular ExternalWebService) but we're talking to SharePoint through the object model. What the heck do I use to represent this? A WebApplication? An ExternalDatabase? A GenericEndpoint? Anyone tried this or have some thoughts on modeling a solution where you're using various parts of Microsoft systems as essentially middleware?

Eli Robillard flipped me a note about a new SharePoint User Group he's starting up in the Toronto area. The first meeting is April 13 so you have plenty of time to get it into your calendar. If you're in the Toronto area, drop by and say hi. His blog entry on it can be found here and the main User Group site can be found here so please RSVP via the website on the meeting invite so Eli knows how many pizza boxes to bring ;)

I don't normally blog twice in the same day, but I was talking to Mike Fitzmaurice about SharePoint Web Parts, Smart Part, ASP.NET 2.0, and migration strategies. He's posted a blog entry that is a sort of roadmap for WSS into 2006 and is an excellent summary of what's going on at Microsquishy. Basically in a nutshell, WSS "v3" is built on top of the ASP.NET 2.0 Web Part Framework and don't plan to use Whidbey Web Parts in SharePoint sites for at least a year. Definately don't deploy ASP.NET 2.0 on your current SharePoint infrastructure unless you're into pain and suffering.

My advice is to crack open that preview copy of Whidbey and the 2.0 framework (when you have time), build some ASP.NET 2.0 Web Parts using the framework and get to know the new classes intimately. They are your friend and a powerful allie they are.

You can check out Mikes full blog entry here.

Over the past month or so fellow SharePoint blogger Bob Mixon has been doing some evaluations with various business process management solutions. He based his criteria on a few things like a GUI for modeling the workflow (for non-developer type guys to get their hands dirty), integration into the core Microsoft infrastructure (including WSS and SPS) and integration with other tools like InfoPath, etc. The result? A fantastic scorecard that gives his overall ranking of the products and rankings on the various criteria he was evaluating against. A most excellent resource for those that are looking in this space and don't know what to do. I did find it interesting he didn't include BizTalk in his eval though. You can check out his blog entry here. Thanks Bob!