Rocky's comments on Test Driven Development

There is fued of sorts between the TDD crowd and Rocky Lhotka. I guess someone forgot to warn Rocky about the TDD crowd. This is the same community that got Microsoft to remove an article about TDD and VS 2005 that was on MDSN...briefly.

Rocky made some comments during a recent episode of DotNetRocks and Jeffery Palermo had some comments to which Rocky responded.

This is very interesting to me because we are using Rocky's .NET Business framework and trying to apply TDD practices with limited success. I would post about them, but I'm afraid I'll get flamed by the TDD crew (kidding, will kinda).

Great .NET Rocks Episodes

I just spent most of today working on my Microsoft SBA Add-in and listening/watching the latest couple episodes of .NET Rocks TV.

In these episodes Jean-Paul Boodhoo explains the Model-view-presenter (MVP) patterns, demonstrates NMock v2 framework, and builds a simple application using Test Driven Development/Design process. He does a great job explaining these concepts while developing a simple web form application. This is well worth your time if you have a couple hours to spare.

COM+/Enterprise Services Configuration

COM+ application components can be configured two ways. They can be configured to run as library applications (in-process) or as a Server application (out of process). Having a library component isn’t a problem since it is running with the application domain as the calling application. However, getting configuration settings into a Server application can be a challenge. So much so, that I typically recommend running a COM+ applications as a library application.

So why is configuration so difficult for server application? Well I’m glad you asked. It’s because the server application is running in a process called dllhost.exe. This process lives in the {Windows}\System32\ directory. The .NET framework “automagically” loads the configuration file named dllhost.exe.config to get the configuration settings as long as it is in the System32 directory. This works great until you have 2 Server components that need different configuration settings. Do you see the problem? 2 Processes – 1 Configuration file. Plus most IT departments freak out (with good reason) when you need to deploy a file to the System32 directory.

If you’ve read this far you’ll find the purpose for this post. I had a colleague send me a link that documents how to use the new options in COM+ 1.5 to use the application directory. This is the only time I’ve heard about using the application.manifest and the application.config files.

http://staff.newtelligence.net/clemensv/PermaLink.aspx?guid=0615b3cc-0fbf-4cf5-9d49-ae95b50f7e8d

 

Database Triggers Rant

The reasons I don't like database triggers:

1.) They are very difficult to debug
2.) They are a type of "magic" within a system. "Magic" is when something happens when I run code that I don't see in the code.
3.) They are not intuitive.

I find that database triggers get used in an organization when one or more of these things happen:
1.) A DBA has been tasked with writing application code
2.) The code is more difficult to change than it is to debug a database trigger
3.) The deployment process for code is significantly longer than the deployment process for SQL changes

FitNesse: Using COM+ Enterprise Services to Manage Transactions

I’ve been working on integrating FitNesse and FIT into my current project. As with all automated testing, managing test data is a challenge.

To manage the data we have 3 options:

1. Abstract the data from the system
   
2. Restore the data to a known state before the tests run
   
3. Create a reciprocating transaction. i.e. Each insert has a corresponding delete
   
4. Rollback the test when it’s completed.

Option 1 is great, but it is difficult to abstract a system from the database especially if you are working with a pre-existing (legacy) system.

Option 2 is viable, but I hate having to do a database restore before I run a test suite.

I’m too lazy for option 3 and wouldn’t pick this option if there are a slew of user acceptance tests(UAT).

So I want to use option 4. Roy Osherove wrote a great article describing how to manage your unit tests using COM+ enterprise services and I have been using this method ever since, however, my tests use “Services Without Components” (SWC) included in COM+ 1.5.

I figured I could you the same concept with FitNesse! My solution is very simple. I created a ColumnFixture that can begin a transaction, commit a transaction, but most importantly rollback a transaction. The Fixture has 2 columns, Action and Result?. The Action column take one of three values: “begin”, “rollback”, and “commit”. The Result? column can be left blank. It will get populated with the System.EnterpriseServices.TransactionStatus after the Result() method is executed.

Now that I have this ColumnFixture, I created two pages: BeginTransaction and RollbackTransaction. These pages will be included before and after, any test fixtures that I want to run within a transaction. I prefer to use FitNesse’s !include widget, but you could also use the SetUp and TearDown pages.

Here's the code.

/// <summary>
    /// This class provides a simple interface to support COM+ transactions.
    /// </summary>
    public class TransactionFixture : ColumnFixture
    {
        public string Action = "begin";
        public string Result()
        {
            TransactionStatus retVal = TransactionStatus.NoTransaction;
            switch(Action.ToLower())
            {
                case "begin":
                    ServiceConfig config = new ServiceConfig();
                    config.Transaction = TransactionOption.RequiresNew;
                    ServiceDomain.Enter( config );
                    break;
                case "rollback":
                    
                    if( ContextUtil.IsInTransaction )
                    {
                        ContextUtil.SetAbort();
                    }
                    retVal = ServiceDomain.Leave();
                    break;
                case "commit":
                    
                    if( ContextUtil.IsInTransaction )
                    {
                        ContextUtil.SetComplete();
                    }
                    retVal = ServiceDomain.Leave();
                    break;
                default:
                    throw new ArgumentException("Invalid value", "Action");
            }

            return retVal.ToString();
        }
    }

Screenshot - Before


Screenshot - After

 

BeginTransaction Page

|!-GiffordConsulting.FitNesseAid.TransactionFixture-!|
|Action|Result?|
|begin||

RollbackTransaction Page

|!-GiffordConsulting.FitNesseAid.TransactionFixture-!|
|Action|Result?|
|rollback||

Putting it all together using import widget

!include BeginTransaction

|!-GiffordConsulting.FitNesseAid.SignonFixture-!|
|Username|Password|Save?|
|Tim|apassword|true|

!include RollbackTransaction

Private Strong-named Assemblies Not Supported

I was surprised to learn (the hard way) this week that Microsoft doesn’t support strong-named assemblies if they are deployed to the \bin directory of an ASP.NET application. If you need proof, check out these links:

 

http://support.microsoft.com/?id=813833

http://support.microsoft.com/?id=324519

 

There are two reasons to sign you assemblies:

1. Install in the Global Assembly Cache (GAC)
2. Install a Serviced Component into a serviced or library Component Services application

 

Once you have signed an assemblies, that assembly can only reference other signed assemblies.

Previously to finding that deploying signed assemblies privately is not supported, I would sign my assemblies whenever I started a new project. This way if I decided down the line that I wanted to install in the GAC, I didn’t have to re-build with a sn.exe key.

Has anyone heard about this?

 

Unit Test Database Code with COM+ (Enterprise Services)

I’ve been using NUnit for a couple years now and love it. However, most of my applications use databases extensively and most of the features within these applications have to do with managing the data in the database. This means I don’t have a lot of business logic for these operations, but I do have a lot of code that interacts with the database. I need unit test for that code. This is where COM+ comes in.

If you have talked to me about unit testing, I have probably mentioned using COM+ with unit tests to rollback any database transactions that occur within the context of the unit test. This means you can insert, update, delete and select data from within your unit test and when the test in completed, all changes will be rolled back. Since I’ve started using it, I can’t live without it. I don’t have any database dependencies with my tests, they are all self supporting. Plus, if you run the tests against a production database (on accident or to troubleshoot) the production data will not be modified.

Roy Osherove gives the details here.

One other tip I just learned that is associated with this method. You can read the “dirty” records within the database if you are stepping thru your COM+ unit tests by changing the transaction isolation level in Query Analyzer.

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED