Posts
74
Comments
71
Trackbacks
0
Monday, June 23, 2008
Code Redundancy is NOT Bad - Part 2

improve my => 'code' Add to Google

I got some responses from a post I made on Saturday, that troubled me.  I really think it is important to code to an interface whenever possible - not only to give your application to flexibilty, but to give it testability as well.  So I thought I might give you an example.

Say I have a class that depends on two other classes I have.  In this example, Partitioner depends on SystemIOAdapter and MerchantRecordCounter.                                                                                                                                                                

                                                                                                                                                                                                                    

using Interfaces;

namespace Program

{

    public class Partitioner : IPartitioner

    {

        public void PartitionMerchants(ISystemIOAdapter io, IMerchantRecordCounter counter, string mappedPath, string partitionPath, int maximumCount)

        {

           // implementation details.

        }

    }

}

If the method PartitionMerchants had been written using class declarations instead of interfaces, than any test I would write for this method would be an integration test, not a unit test...  Because the failure could be in one of the dependent classes, not in the class that is under test in my unit test! 

Integration tests are useful as smoke tests to identify that a problem exists.  But they don't help me quickly identify the root cause of problems when they arise.

The following shows a unit test for a Partitioner class that depends on a SystemIOAdapter (so dependencies on a specific IO is removed),  and a MerchantrecordCounter class.  You may notice that the only way to mock these out are by creating classes that implement the same interfaces used in the PartitionMerchants method.  (In this case I am using Rhono Mocks to do this quickly).

using Project.Interfaces;

using NUnit.Framework;

using Rhino.Mocks;

namespace Tests

{

    [TestFixture]

    public class Partitioner_UT

    {

        private MockRepository mocks;

        private string mappedpath = "mappedpath";

        private string partitionedpath = "partitionedPath";

        private ISystemIOAdapter io;

        [SetUp]

        public void SetUp()

        {

            mocks = new MockRepository();

            io = mocks.CreateMock<ISystemIOAdapter>();

        }

         [Test]

        public void PartitionDirectory_OnlyOneMerchantFound()

        {

            IMerchantRecordCounter counter = mocks.CreateMock<IMerchantRecordCounter>();

            using (mocks.Record())

            {

                // set up call expectations here

            }

            using (mocks.Playback())

            {

                IPartitioner partitioner = new Partitioner();

                partitioner.PartitionMerchants(io, counter, mappedpath, partitionedpath, 0);

                // Add assertions here

            }

        }

    }

}

I hope this clears up why it is so important to write code using interfaces whenever possible!

Jonathan Starr

posted @ Monday, June 23, 2008 6:26 PM | Feedback (2)
News
Jonathan Starr is a developer in Saint Louis, MO. He holds an MBA in Finance from Columbia Business School and earned his MCSD from Microsoft.


All statements in this blog are personal opinions and do not reflect the opinions of his employer.





Related Sites
Join My Community at MyBloglog!

Tag Cloud