Wayne Allen's Weblog

Writing Testable Code - Story: Retrieve RSS Feeds

See http://dotnetweblogs.com/Wallen/posts/4065.aspx for backgound info.

Story Name: Retrieve RSS feed(s) and display as posts in Outlook folder

Description: Retrieve each of the subscribed RSS feeds and create a "post" message in the News folder for each RSS item.

Details:

•  The "from" column will be the RSS channel title
• The "subject" column will be the RSS item title
• The "body" will be the RSS item description
• The "sent" column will be the RSS item pubDate
• The "received" column will be the time the item was processed
• All feeds will be put in the same folder (News)
• Each item will only be added to the list once (no duplicate posts)
• A duplicate is determined by comparing from, subject and body

Tasks:

• Get a list of RSS feeds
• Retrieve a RSS feed
• Determine if a RSS feed item is a duplicate
•  Create a post from an RSS feed item and add it to the News folder

Writing Testable Code - Introduction

I've had a keen interest in the way testable code is different than non-testable code. To help me explore the differences more fully I plan to write a series of posts that chronicle my experiences, insights and failures.

Both test driven development (TDD) and mock objects have provided good insight into what is different at the code level for new development. However, missing from the equation is the down and dirty of dealing with GUIs, databases, and legacy code.

To start with I also am going to take the easy path of new development as I explore the development of a news aggregator similar to NewsGator (http://www.newsgator.com/) by Greg Reinacker (http://www.rassoc.com/gregr/weblog/default.aspx).

I choose this project because it is limited in scope, but still explores areas such as 3rd party libraries (MS Outlook), non-deterministic behavior (http gets) without getting into GUIs and databases.

Initial Story List:

• Retrieve RSS feed(s) and display as posts in Outlook folder.
• Subscribe to RSS feed

Goals:

• Show how unit tests change the design of code
• Show how mock objects change the design of code
• Identify any common patterns
  

Root Canal

Lucky me had a root canal today. My dentist told me I had the longest roots he had ever seen, whoopee! What that means in practical terms is that the tools they use for cleaning out the canal wan't quite long enough and that I'll have to rely on antibiotics to make sure I don't have any problems.

I am glad I live in an era with good pain killers, although my overall experience wasn't bad (I've had worse fillings).

Windows Update, Good vs. Evil

Scott H. pointed out that they typically disable Windows Update on their production servers.  Makes perfect sense to me.  On the other hand, I want Windows Update to pull updates for EVERYTHING on my dev box.  I don't want to look for Office patches, SQL patches, MapPoint patches, etc., etc.  I want a Just Patch Everything button.

I'm curious what people think about Windows Update.  Good?  Evil?  Both?

We have a policy of keeping our dev servers up to date via Windows Update to ensure the latest patch/hotfix/service pack/whatever doesn't bite us when IT updates the staging & production servers.

See Windows Server 2003, and something called...being a Security Expert from Scott H.

Having worked at Corillian with Scott H for a while I understand their need to control this to the nth degree, but whether everyone needs this level of lock-down is questionable.

Writing nAnt Tasks

I finally broke down and started writing my own set of nAnt Tasks to control version (revision) numbering and updating the AssemblyInfo.cs files so our deployed assemblies will finally have the real version number embedded in them. I expect there is documentation somewhere on the best way to do this, but I went with the "if all else fails read the documentation" approach.

My first goal was to get my task working without any of the nant framework. I didn't want some subtle issue causing problems on the basic stuff.

Here is the basic premise of the tasks:

• get the current version
• increment the revision
• update the AssemblyVersion pseudo-attribute (i.e. modify the file)

I am specifically excluding the meta tasks of dealing with version control of the AssemblyInfo.cs file as that is better handled by the vss and cvs tasks.

I should note that I am most interested in manipulating the revision part of the complete version number (major.minor.build.revision) as the other parts are determined by the product managers.

Similar to John Lam's approach I am going to store the version information in a separate file so it can be placed under source control as well. Contrary to John's approach the only option the version task will have is whether to increment or not.

BuildIt

BuildIt is a new build tool from MS (via Sapient Corp.)

BuildIt.NET is designed to jump-start the build process used for development of .NET distributed applications. This download provides full source code and comprehensive documentation for the Microsoft Visual C#® development tool and Microsoft Visual Basic® .NET development system.

A quick review shows that it seems to do the following:

• Maintain build numbers - I.e. increments the build number and updates the AssemblyInfo.* files and labels the project in VSS.
• Build single and multiple solution projects - multi solution builds must list the solutions in dependency order (i.e. no declarative dependencies like nAnt)
• Create build logs - these can be mailed via SMTP
• Archives generated assemblies - I.e. copy the results to a folder named after the build number.

The functionality is so limited (no extensibility, requires solution files, requires VSS, required VS.NET, etc) I can't understand why anyone would use this in place of nAnt. However, MS is known for throwing a basic solution out and then gradually refining it until they get it right.

Interestingly the builds are accomplished through VS.NET automation rather than through devenv.exe. Presumably this is to support building with any framework version.

The thing I am interested in is the way they update the AssemblyInfo.* files. Basically they just read the entire file in and do a RegEx replace using the pattern '(?<1>\<Assembly: AssemblyVersion\(""\d+\.\d+\.)[\d\*]*(?<2>.*)' (for C#) and then write it back.