Testing every implementer of an interface with the same tests using MSTest

You have an interface and multiple implementers of that interface. You want to test all those implementing classes using the same tests. Using a unit test framework like NUnit that is a breeze.

But you, you use MSTest, the Microsoft Unit Testing Framework.

So, just for fun, you try porting the example in NUnit post on testing implementers of an interface to the Microsoft Unit Testing Framework.

And run into all manner of problems. But fear not. There is a solution and it actually is pretty easy to boot.

The journey

1. Convert the attributes

For your first try using MSTest, you basically copy the code and rename the attributes. TestFixture becomes TestClass and Test becomes TestMethod.

As the TestClass attribute doesn’t support any arguments, you take them off, leaving you with a single, bare TestClass attribute. That’s a hint by the way that you have no easy way of telling MSTest for which classes to run these tests…

2. Mark the class and methods public

MSTest requires every class that contains test methods and every method to be run as a test to be public, or it won’t play ball and ignores them regardless of the attributes. So you dutifully add the public accessibility level to both the class and our single test method.

    class PieceOfWood_Fake : IPieceOfWood {}

    [TestClass]
    public class IJointer_Contract_MS<T> where T : IJointer, new()
    {
        IJointer MakeJointer()
        {
            return new T();
        }

        [TestMethod]
        [TestCategory("Jointer")]
        public void MakeDoveTailJoint_No_Exceptions_Raised_Should_Return_Non_Null_DoveTailJoint()
        {
            var jointer = MakeJointer();
            var DoveTailJoint = jointer.MakeDoveTailJoint(new PieceOfWood_Fake(), new PieceOfWood_Fake());
            Assert.IsNotNull(DoveTailJoint);
        }
    }

That comes back to bite you in the behind though with the compiler complaining:

Inconsistent accessibility: constraint type 'ActualProject.InterfaceContract.IJointer' is less accessible than 'TestProject.InterfaceContract.IJointer_Contract_MS'

Duizend bommen en granaten![1]

You really don’t want to make the code in your actual project any more accessible from the outside than absolutely strictly necessary. Catering to unit tests is never a good reason to increase the accessibility level and while IJointer may be an interface, it still is an internal implementation detail of the actual project and should remain so.

Introduce a public base interface?

Could you get around this by introducing a public “test” interface that IJointer can derive from? It does mean adding a superfluous interface to the actual project, but you’ll take that over increasing IJointer‘s accessibility level.

    public interface IAny {}

    interface IJointer : IAny
    {
        IDoveTailJoint MakeDoveTailJoint(IPieceOfWood woodTails, IPieceOfWood woodPins);
    }

And you can now declare the testclass using the public IAny, which keeps the compiler happy.

    [TestClass]
    public class IJointer_Contract_MS<T> where T : IAny, new()
    {
        IJointer MakeJointer()
        {
            return new T() as IJointer;
        }
    }

3. Tell MSTest for which classes to run the tests

Now that you have a generic test class that can be used to test all classes implementing the IJointer interface, you need a way to tell MSTest for which classes to do so. That would be both the FirstJointer and SecondJointer classes from the NUnit example.

Deriving a specific test class from the generic test class?

As the TestClass attribute does not support constructor arguments like NUnit’s TestFixture attribute, that’s out, so … what about deriving a specific class from the generic one?

    [TestClass]
    public class IJointer_FirstJointer : IJointer_Contract_MS<FirstJointer> { }

Looks good, but… Nope.

That runs into the exact same problem with regard to accessibility levels as you faced with the IJointer interface.

Inconsistent accessibility: base class 'TestProject.InterfaceContract.IJointer_Contract_MS' is less accessible than class 'TestProject.InterfaceContract.IJointer_FirstJointer'

Introduce a public base class?

You could create a public abstract AnyJointer class that every IJointer implementer could derive from.

    public abstract class AnyJointer : IJointer 
    {
        public abstract IDoveTailJoint MakeDoveTailJoint(IPieceOfWood woodTails, IPieceOfWood woodPins);
    }

    class FirstJointer : AnyJointer
    {
        public override IDoveTailJoint MakeDoveTailJoint(IPieceOfWood woodTails, IPieceOfWood woodPins)
        {
            return new FirstDoveTailJoint();
        }
    }

But, really, could derive from? Doing it like this means “could” becomes “should”. And that totally defeats (one of) the object(s) of using interfaces! You would no longer be free to make any class implement IJointer. Every class implementing IJointer would now have to fit into a very specific class hierarchy.

And it is not even going to work, because

    [TestClass]
    public class IJointer_FirstJointer : IJointer_Contract_MS<AnyJointer> { }

would make

    public class IJointer_Contract_MS<T> where T : IAny, new()
    {
        IJointer MakeJointer()
        {
            return new T() as IJointer;
        }
    }

instantiate the AnyJointer class, which, besides being impossible as it is abstract – easily overcome by not marking it such, is not what you need. You need instances of the FirstJointer and SecondJointer classes to test againt the IJointer interface contract.

Mark MakeJointer virtual?

To make the IJointer_FirstJointer test class return a FirstJointer instance you can make MakeJointer virtual in the contract class and override it.

    public class IJointer_Contract_MS<T> where T : IAny, new()
    {
        internal virtual IJointer MakeJointer()
        {
            return null;
        }
    }

And, better, mark it abstract so derived test classes are required to override it.

    public abstract class IJointer_Contract_MS<T> where T : IAny, new()
    {
        internal abstract IJointer MakeJointer();
    }

Notice that this requires you to mark the contract class abstract as well or you will get compiler errors.

But, but, but… that totally defeats the object of defining a generic test class!

Back to square one then?

In a sense, yes. And in this case, that is a good place to be.

If you ditch the generic test class, then you can also ditch everything you did to work around MSTest’s requirement that every test class and every test method should be public.

So you scrap IAny and AnyJointer in the actual project, which puts everything in there back to having an internal accessibility level only. Yay!

The solution

When you are using the Microsoft Unit Testing Framework and you want to leave everything in your actual project with no more than the internal accessibility level it should have, then to test every class implementing the IJointer interface with the same tests, you need to

  • use an abstract test class that defines the tests to be run, and
  • define specific test classes for each class implementing the interface.

1. Define an abstract base test class

    [TestClass]
    public abstract class IJointer_Contract_MS
    {
        internal abstract IJointer MakeJointer();

        [TestMethod]
        [TestCategory("Jointer")]
        public void MakeDoveTailJoint_No_Exceptions_Raised_Should_Return_Non_Null_DoveTailJoint()
        {
            var jointer = MakeJointer();
            var DoveTailJoint = jointer.MakeDoveTailJoint(new PieceOfWood_Fake(), new PieceOfWood_Fake());
            Assert.IsNotNull(DoveTailJoint);
        }
    }

2. Derive a specific test class per implementer

To make MSTest run the contract tests for each class implementing the IJointer interface, you have to derive a specific test class for each of them manually and provide each with its own implementation for the MakeJointer method.

    [TestClass]
    public class IJointer_FirstJointer : IJointer_Contract_MS 
    {
        internal override IJointer MakeJointer() { return new FirstJointer(); }
    }

    [TestClass]
    public class IJointer_SecondJointer : IJointer_Contract_MS
    {
        internal override IJointer MakeJointer() { return new SecondJointer(); }
    }

3. See the classes being tested against the same contract

MSTest_IJointer_First_And_SecondJointer

All in all a bit more work than using a generic test class and the TestFixture attribute as you can with NUnit, but not too bad at all.

That’s it. Enjoy!

What piece of code had you wondering how to get it under test? Please do feel free to let me know! I’d love hearing from you by email or in the comments below. I read everything and will try to help where and as best I can.

[1] Dutch version of a Captain Haddock expletive. Literal translation: “Thousand bombs and grenades!”. Closest English version is probably the “Ten thousand thundering typhoons!” one.

Posted in Software Development
Tags: , , , , , , , , , , ,

Testing every implementer of an interface with the same tests using NUnit

You have an interface and multiple implementers of that interface. You want to test all those implementing classes using the same tests. Using a unit test framework like NUnit that is a breeze.

You write the tests once. Using a reference to the interface in all of them. And then you tell your test runner to run these tests for every class that implements it. This way you test all these classes against the contract of the interface. Contract testing, pure and simple.

Let’s take another stab at dovetail joints:

    interface IJointer
    {
        IDoveTailJoint MakeDoveTailJoint(IPieceOfWood woodTails, IPieceOfWood woodPins);
    }

    interface IDoveTailJoint {}

    interface IPieceOfWood {}

Any implementer of the IJointer interface needs to honor the following contract for the MakeDoveTailJoint method:

  • Should throw ArgumentNullException when woodTails is unassigned
  • Should set ParamName of ArgumentNullException to woodTails when woodTails is unassigned
  • Should throw ArgumentNullException when woodPins is unassigned
  • Should set ParamName of ArgumentNullException to woodPins when woodPins is unassigned
  • Should return non-null reference to a DoveTailJoint when no exceptions are thrown
  • Should return DoveTailJoint with at least 1 tail
  • Should return DoveTailJoint with non-zero TailWidth
  • Should return DoveTailJoint with non-zero TailLength
  • Should return DoveTailJoint with non-zero FullPinWidth
  • Should return DoveTailJoint with non-zero SidePinWidth
  • Should return DoveTailJoint that fits woodTails’ width: ((number of tails) * TailWidth) + (((number of tails) – 1) * FullPinWidth) + (2 * SidePinWidth)

Once you know how to do it for one of these contract requirements, you can easily extend this to the others, so for brevity’s sake let’s focus on “Should return non-null reference to a DoveTailJoint when no exceptions are thrown”. The method to check this behavior would be something like:

    class PieceOfWood_Fake : IPieceOfWood {}

    public void MakeDoveTailJoint_No_Exceptions_Raised_Should_Return_Non_Null_DoveTailJoint()
    {
        var jointer = MakeJointer();
        var DoveTailJoint = jointer.MakeDoveTailJoint(new PieceOfWood_Fake(), 
            new PieceOfWood_Fake());
        Assert.IsNotNull(DoveTailJoint);
    }

So far so good. Now, you need to implement the MakeJointer method in such a way that when you run this method for the FirstJointer class, it returns an instance of FirstJointer and when you run it for the SecondJointer class, it returns an instance of SecondJointer.

Using NUnit, you can very simply do this by declaring a generic test class and constraining it so it can only be used for (types deriving from) IJointer:

    class IJointer_Contract<T> where T : IJointer, new()
    {
        IJointer MakeJointer() 
        {
            return new T();
        }

        public void MakeDoveTailJoint_No_Exceptions_Raised_Should_Return_Non_Null_DoveTailJoint()
        { // ... snip ... }
    }

The new() constraint on the class declaration enables you to create new instances of T. Without it, the compiler complains with the error message “Cannot create an instance of the variable type ‘T’ because it does not have the new() constraint” on the return new T(); line.

Now that you have a generic test class that can create a reference to IJointer, you still need to tell NUnit to run all the test methods in this class for every class implementing the IJointer interface.

With NUnit, that is as easy as adding an attribute to the test class:

    [TestFixture(typeof(FirstJointer))]
    [TestFixture(typeof(SecondJointer))]
    class IJointer_Contract<T> where T : IJointer, new()
    {
        // ... snip ...
    }

NUnit’s TestFixture attribute makes NUnit run the tests in the IJointer_Contract<T> test class with T substituted by the class specified in the attribute. In the above example, NUnit will run all the tests in IJointer_Contract<T> for both the FirstJointer and the SecondJointer classes.

IJointer_Tests_NUnit
Yeah, I know, the test fails… The Jointer classes still only satisfy the compiler by having return null; as their implementation for the MakeDoveTailJoint method. The other tests succeed only because the tests themselves are not yet implemented. See my moan about this in How to test a class hierarchy without repeating yourself.

That’s it. Enjoy!

What piece of code had you wondering how to get it under test? Please do feel free to let me know! I’d love hearing from you by email or in the comments below. I read everything and will try to help where and as best I can.

Posted in Software Development
Tags: , , , , , , , ,

How to test a class hierarchy without repeating yourself

You don’t want to spend your effort on futile tasks. And testing all methods of a base class and then testing them again for every descendant sounds futile.

After all, non virtual methods are not going to change in a descendant, so, really, testing the base should be enough? And what’s the use of testing the virtual methods of an ancestor when they are going to be overridden by the descendants anyway?

As non virtual methods can’t be overridden by descendants, why run the ancestor’s tests for all descendant classes as well?

But, what about non-virtual methods that call out to a virtual method? Shouldn’t they be tested to evaluate the effect of overriding the virtual method? Adhering to the Liskov substitution principle means that a descendant’s behavior should not contradict its ancestor’s behavior contract. So while you can override methods of your base class, you can’t do so willy-nilly.

It is in fact a very good idea to run the ancestor’s tests for all descendants to ensure that none of them violate their base’s behavioral contract. And while you perhaps would only really have to do so for virtual methods and any non-virtual methods that use a virtual one, penny pinching by not testing non-virtual methods for each descendant may come and bite you in the behind pretty quickly.

After all, what’s to keep someone from adding such a call at a later stage? And what are the chances of forgetting to add the unit tests that are now needed for the descendant classes? They after all haven’t been changed, so there is no trigger to add to their tests. Forgetting to add them at that stage means your safety net’s holes just got bigger.

Wouldn’t it be far more preferable to just always test all public and protected methods, regardless of their “virtual” status, so that when such a change is made no manual action is required to maintain your safety net?

Yes, of course, but … YOU DO NOT WANT TO REPEAT YOURSELF.

There is no need to do so.

Test classes are first class citizens too. They too can put inheritance to good use.

To ensure that the tests for the base class are run for all descendants and that you only need to add tests for a descendant that are specific to that descendant, you create a parallel hierarchy of test classes.

Too abstract?

Okay, let’s get specific and have some fun with one of my hobbies.

For 10+ years I was a hobby solid wood furniture maker. Dovetail joints were my nemesis. They are daunting at first and you follow the rules to the T just to keep on top of them. As your skills improve with more practice, you free yourself more and more from the rigidity of the rules and start playing around with the dimensions of the tails and pins. However, even as a master craftsman (which I am anything but) you still have to conform to the basics.

DoveTails HalfBlindDoveTails MarkingOutDoveTails SingleDoveTail

An apprentice and a master dovetail jointer may have very individual approaches to deciding how many tails there will be, how wide they will be and how they will be spaced. Yet both still have to adhere to the basic rules for dovetails though. If that doesn’t sound like a base class with two derived classes to you, it certainly does to me.

Jointer Class Diagram - Actual Classes

To test this tiny hierarchy, you create a parallel hierarchy of test classes.

Jointer Class Diagram - Tests Classes

The BaseJointer_Tests class get the tests for all behavior that any Jointer should provide.
The ApprenticeJointer_Tests and MasterJointer_Tests classes both derive from the BaseJointer_Tests class, thus inheriting all the tests for general jointer behavior, and each add their own tests to verify the behavior specific to themselves.

Still too abstract?

Let’s add some code then. First the BaseJointer class. A pretty simple thing. It has a non-virtual method to make a dovetail joint for joining two pieces of wood. It has a couple of virtual methods that allow derived classes to customize how the dovetail joint will look.

    class BaseJointer
    {
        public DoveTailJoint MakeDoveTailJoint(PieceOfWood woodTails, PieceOfWood woodPins)
        {
            int numberTails = DecideNumberOfTails(woodTails, woodPins);
            int tailWidth = DecideTailWidth(woodTails, numberTails);
            int tailLength = DecideTailLength(woodTails, woodPins);

            return new DoveTailJoint(numberTails, tailWidth, tailLength, woodTails.Width);
        }

        protected virtual int DecideNumberOfTails(PieceOfWood woodTails, PieceOfWood woodPins)
        {
            return 1;
        }

        protected virtual int DecideTailWidth(PieceOfWood woodTails, int numberTails)
        {
            return 1;
        }

        protected virtual int DecideTailLength(PieceOfWood woodTails, PieceOfWood woodPins)
        {
            return 1;
        }
    }

The rules that MakeDoveTailJoint needs to follow, its requirements if you like, are:

  • Should throw ArgumentNullException when woodTails is unassigned
  • Should set ParamName of ArgumentNullException to woodTails when woodTails is unassigned
  • Should throw ArgumentNullException when woodPins is unassigned
  • Should set ParamName of ArgumentNullException to woodPins when woodPins is unassigned
  • Should return non-null reference to a DoveTailJoint when no exceptions are thrown
  • Should return DoveTailJoint with at least 1 tail
  • Should return DoveTailJoint with non-zero TailWidth
  • Should return DoveTailJoint with non-zero TailLength
  • Should return DoveTailJoint with non-zero FullPinWidth
  • Should return DoveTailJoint with non-zero SidePinWidth
  • Should return DoveTailJoint that fits woodTails' width: ((number of tails) * TailWidth) + (((number of tails) – 1) * FullPinWidth) + (2 * SidePinWidth)

The current implementation of BaseJointer is not meeting these rules of course, but that is beside the point of this post. These rules, requirements, become the tests in the BaseJointer_Tests class.

    [TestClass]
    public class BaseJointer_Tests
    {
        [TestMethod]
        public void MakeDoveTailJoint_woodTails_Unassigned_Should_Throw_ArgumentNullException() { }

        [TestMethod]
        public void MakeDoveTailJoint_woodTails_Unassigned_Should_Set_ParamName_Of_ArgumentNullException() { }

        [TestMethod]
        public void MakeDoveTailJoint_woodPins_Unassigned_Should_Throw_ArgumentNullException() { }

        [TestMethod]
        public void MakeDoveTailJoint_woodPins_Unassigned_Should_Set_ParamName_Of_ArgumentNullException() { }

        [TestMethod]
        public void MakeDoveTailJoint_No_Exceptions_Raised_Should_Return_Non_Null_DoveTailJoint() { }

        [TestMethod]
        public void MakeDoveTailJoint_Should_Return_DoveTailJoint_With_At_Least_1_Tail() { }

        [TestMethod]
        public void MakeDoveTailJoint_Should_Return_DoveTailJoint_With_Non_Zero_TailWidth() { }

        [TestMethod]
        public void MakeDoveTailJoint_Should_Return_DoveTailJoint_With_Non_Zero_TailLength() { }

        [TestMethod]
        public void MakeDoveTailJoint_Should_Return_DoveTailJoint_With_Non_Zero_FullPinWidth() { }

        [TestMethod]
        public void MakeDoveTailJoint_Should_Return_DoveTailJoint_With_Non_Zero_SidePinWidth() { }

        [TestMethod]
        public void MakeDoveTailJoint_Should_Return_DoveTailJoint_That_Fits_woodTails_Width() { }
    }

According to TDD you should write one test, make it pass, refactor and then write another test, but I just can’t work that way. It makes me lose sight of the overall picture. I like to use what is known as a “test list”. TDD’ist would probably keep that list outside of the code and there are certainly arguments to do so. Me, I just keep ‘em in my code as empty test methods.

Currently with most test frameworks, I am forced to use `[Ignore]` attributes or `Assert.Inconclusive` calls to have them not show as failing, while still serving as “To Do”‘s. I do wish frameworks would mark any empty test method as “Ignore – to be implemented” automatically. In fact I would love if they did so automatically as well for test methods that are not empty but do not call a single `Assert` member.

Have any suggestions for me on how to achieve what I want easily? Please let me know!

Every descendant of BaseJointer should be tested against these same rules, without repeating them in each test class companion of every descendant. As mentioned above, the solution is to derive these test classes from the BaseJointer_Tests class:

    [TestClass]
    public class ApprenticeJointer_Tests : BaseJointer_Tests
    {
        [TestMethod]
        public void Extra_Test_Specifically_For_ApprenticeJointer()
        {
            // ... snip ...
        }
    }

When you do that for the MasterJointer_Tests class as well, then running the tests would show that all tests in the BaseJointer_Tests class are run also for both the ApprenticeJointer_Tests and MasterJointer_Tests. Also notice the extra test defined for each derived test class.

JointerTestExplorer
Note: I commented out most of the tests in the BaseJointer_Tests class for brevity.

Nice ha? You are testing everything without repeating yourself!

Now, to the tiny matter of implementing a test in the BaseJointer_Tests class. The naive way would be to do something like:

    [TestMethod]
    public void MakeDoveTailJoint_woodTails_Unassigned_Should_Throw_ArgumentNullException()
    {
        var jointer = new BaseJointer();
        jointer.MakeDoveTailJoint(null, new PieceOfWood());
    }

But that foils your goal of testing descendants of BaseJointer against the same set of rules. The inheritance we set up isn’t going to help you if the test instance you create is always an instance of BaseJointer. You need it to be a BaseJointer only when running the tests for the BaseJointer class. When you run the tests for ApprenticeJointer or MasterJointer you need the object under test to be an instance of that class, even when running the tests in BaseJointer_Tests.

The answer is to use a virtual “factory” method:

    protected virtual BaseJointer MakeJointer()
    {
        return new BaseJointer();
    }

and use that in your tests when you need a Jointer instance:

    [TestMethod]
    public void MakeDoveTailJoint_No_Exceptions_Raised_Should_Return_Non_Null_DoveTailJoint()
    {
        var jointer = MakeJointer();
        var DoveTailJoint = jointer.MakeDoveTailJoint(new PieceOfWood(), new PieceOfWood());
        Assert.IsNotNull(DoveTailJoint);
    }

Now when you run the tests, the object under test always matches the class being tested.

And every descendant of BaseJointer_Tests can use the instance MakeJointer() even for tests added specifically to exercise their own class under test. Thus putting the ability to substitute the base for any derived class to good use.

    [TestMethod]
    public void Extra_Test_Specifically_For_MasterJointer()
    {
        var jointer = MakeJointer();
        jointer.MakeDoveTailJoint(new PieceOfWood(), new PieceOfWood());
        // ... any asserts you need
    }

The only time you would need to cast the instance to the specific class is when testing methods that only appear in a derived class. And you don’t even have to do that. You could also add another factory method to the derived test class to return a reference to the exact class:

    protected ApprenticeJointer MakeApprenticeJointer()
    {
        return new ApprenticeJointer();
    }

You can make this one virtual as well if there are classes deriving from ApprenticeJointer

    [TestMethod]
    public void Extra_Test_For_Method_Specific_To_ApprenticeJointer()
    {
        var jointer = MakeApprenticeJointer();
        jointer.DoSomethingSpecificToApprentices();
        // ... any asserts you need
    }

That’s it. Enjoy!

What piece of code had you wondering how to get it under test? Please do feel free to let me know! I’d love hearing from you by email or in the comments below. I read everything and will try to help where and as best I can.

Posted in Software Development
Tags: , , , , , , ,

Three reasons why it is hard to get people to adopt better practices

1. Simple <> Easy

Good practices often revolve around making things simpler, making them less convoluted and complicated, putting everything in its own place instead of letting stuff spread around.

Simple does not mean easy though.

Making something simpler is hard work. Untangling a big complicated mess takes significant cognitive effort. It is often easier to leave the complicated mess in place, adding to it, even if we know it may come back to haunt us.

There is no expedient to which a man will not resort to avoid the real labor of thinking.
– Sir Joshua Reynolds

Research shows that our brains and psychology actively predispose us to avoid the hard work of thinking clearly and to rely heavily on automatic behavior tapes to reduce the burden of having to make decisions based on clear thinking.

So, we tend to stick with what we know and have.

2. Short term rewards

The rewards of good practices, such as simplifying things all the time, often are not immediately apparent. Usually they manifest themselves only when returning to something.

And when we reap their benefits, the reduced effort required on the revisit is not attributed to the effort expended to make things as simple as possible, but rather is taken for granted.

So, we all too readily fall prey to the allure of short term rewards and avoid the hard work of ensuring a slightly slower but much more sustainable pace in the long term.

3. Inconvenient truths

Sometimes it is not the effort of hard cognitive work that makes us shirk thoughtful activity, but the harsh consequences of that activity. Sometimes it is the cursedly clear and unwelcome set of answers provided by straight thinking that makes us mental slackers. There are certain disturbing things we simply would rather not realize.
– Robert B. Cialdini

We would rather look the other way and continue as we did before rather than acknowledging that we may have made a bad decision and taking steps to correct that. We even construct reasons why our bad decisions were “actually” good ones.

It’s human nature

Just like good judgement is the result of experience and experience is the result of bad judgement, good practices are the result of experience and experience is the result of bad practices.

Good judgement and the willingness to expend the effort required to practice good habits usually only comes after having had many, many, many first hand experience with the troubles caused by bad practices.

That is why it is so hard to convince people to adopt good practices. If you haven’t felt the pain, it is hard to justify the effort for an (as yet) unfelt gain.

It’s not that we are lazy, foolish or pigheaded. It’s just our human nature working against us.

Or is it?

Are we doomed?

Of course not. Quite the contrary. Human nature is an interesting beast. You can put it to work to your advantage just as well.

If people are hard-wired to default to turning off their energy sucking thought processes, reduce the number of things they need to think about. Interestingly, you do that by making things simpler, and thus reducing what you have to worry about when implementing your shiny new feature one aspect at a time.

If people like short term rewards more than long term gains, focus on the short term gains. The red-green-refactor cycle is addictive whether you TDD or not. It makes you feel in control despite the frustrations of getting legacy code under test. And feeling in control makes you more confident in what you are doing. Who wouldn’t want that?

If people don’t like realizing they may have made a bad decision in the past, ignore that and focus on making things a little better now. I was foolish enough to think everybody would simply love to improve. But improving implies you did something less well than you could have. For some, that realization hurts more than the joy of continually getting better. I wish for you not to have to overcome the resistance that evokes. So don’t talk about improving, just do it. Focus on what you can do to make bad things not happen again and good things happen more often. Haven’t quite gotten the hang of this myself yet. It’s something I am improving :) If you have any tips, I’m all ears.

Blindingly obvious? Yes.

Simple? Yes.

Easy? Not so much.

First steps?

  • Show, don’t tell.
  • Start small. Work with one person at a time. Show, don’t tell is much easier when you can do it one-on-one with a very concrete bit of code that you are working on, now.
  • Start small. It’s much less daunting to figure out how to improve one function or how to bring one method of a class under test.
  • Keep taking small steps. Keep in mind that you can always improve something again. And again, and again. There is no need to get it perfect the first time around, or the second, or the third. Heck, if you got it perfect at any time you would have to forego the pleasure of getting better. Where is the fun in that?
  • Celebrate every step in the right direction.
  • Enjoy the journey.

More thoughts on how to move towards better practices in some future post.


Have any war stories?
How have people exasperated you by stubbornly continuing not-so-good practices in spite of overwhelming arguments to adopt better ones?
How did you get someone enthusiastic about a new approach?
I’d love hearing from you by email or in the comments.

Posted in Software Development
Tags: , , , , ,

Property.Settings.Default makes it hard to unit test any method that uses it

Storing your application and user settings should be a solved problem. After all, we have done it since the dawn of software development. Yet, the question “What is the best way to store settings?” keeps cropping up. The answers vary widely and quite often spark religious wars.

As interested as I am in why people are so invested in whatever they use, it doesn’t help me decide one way or the other.

Does it really matter? It’s not like it is a life and death decision.

Just use what is provided by your development environment and be done with this already!

Using Visual Studio, that would mean you opt for using Properties.Settings.Default.

The reasons to do so are obvious:

  • It’s the recommended way to store settings for Windows Forms Applications by 283 upvotes on StackOverflow [1], as well as by CodeProject [2] and of course MSDN [3] itself.
  • The Visual Studio Settings designer generated a settings class that allows you to work with your settings in a type safe manner. Much better than the ToString / FromString hell that is ConfigurationManager.AppSettings.
  • It’s quick and convenient. No coding required.

All you need is something like:

    class SettingsMineField
    {
        public Int MethodReadingSomeSetting()
        {
            // <snip>
            string LastFolder = Properties.Settings.Default.LastUsedFolder;
            // <snip>
            return Whatever;
        }

        public void MethodWritingSomeSetting(string newValue)
        {
            // <snip>
            Properties.Settings.Default.LastUsedFolder = newValue;
            Properties.Settings.Default.Save();
            // <snip>
        }
    }

Sounds good, hah?

But… what about testing that those methods do what they are supposed to do and keep doing so in future as well?

Using Properties.Settings.Default throughout your code:

  • You bind yourself hand and foot to whatever storage mechanism you hook up (by default the app.config and user.config files).
  • You turn every function that uses Properties.Settings.Default into something that can only be tested through slow integration tests instead of quick, fast executing and more focused unit tests.
  • You will have a hard time to arrange your tests properly as it turns out that is a lot of work, even somewhat of a hack, to get Properties.Settings.Default to work with test content instead of the actual application and user configuration files. [4], [5]

In short, you dig yourself into a hole when it comes to testing your application. If you care about unit testing your code at all, the reasons not to use Properties.Settings.Default are obvious as well.

What to do? How do you get the benefits of using Properties.Settings.Default without the drawbacks?

Dependency injection comes to mind. Which could look something like this:

    class HappyCamper
    {
        Properties.Settings _Settings;

        public HappyCamper(Properties.Settings useThisSettingsInstance)
        {
            _Settings = useThisSettingsInstance;
        }

        public Int MethodReadingSomeSetting()
        {
            // <snip>
            string LastFolder = _Settings.LastUsedFolder;
            // <snip>
            return Whatever;
        }

        public void MethodWritingSomeSetting(string newValue)
        {
            // <snip>
            _Settings.LastUsedFolder = newValue;
            _Settings.Save();
            // <snip>
        }
    }

However, as Properties.Settings is a sealed class, there is no way to circumvent the standard behavior of that class. And, where the resources mentioned above sought to force the configuration management framework to use files with test content instead of the actual files, you want to go one better.

You want your actual program to reap the benefits of the built-in configuration management, and you want your tests independent of the app.config and user.config files (or any other storage mechanism that the built-in configuration management provides) to make them part of your fast executing unit test suite.

So… you need to sever the umbilical cord between the code using settings and the configuration files. If that sounds like breaking a dependency to you: Yay! That is exactly what it is.

If you can’t change or easily influence the (default) behavior of some built-in class, the answer is to insulate your code from the trouble by introducing a layer over which you do have total control. Whether you do so by inheritance or composition doesn’t matter. Either method will provide you with the seams you need to fake the settings used by the code under test.

Inheritance has the advantage of making all standard behavior immediately accessible with very little extra code. Composition takes a bit more work: you need to “replicate” the properties and methods the rest of your code needs and patch them through to the wrapped class. Despite that, I generally prefer composition. It ensures that the properties and methods of and the types used by the wrapped class do not leak into the rest of my code.

As the Properties.Settings class is sealed, inheritance is out.

Wrapping Properties.Settings for our example above:

    class HappySettings
    {
        Properties.Settings _Settings;

        public HappySettings()
        {
            _Settings = Properties.Settings.Default;
        }

        public string LastUsedFolder 
        { 
            get { return _Settings.LastUsedFolder; } 
            set { _Settings.LastUsedFolder = value; } 
        }
        public void Save() { _Settings.Save(); }
    }

Which allows the SettingsMineField class that we started with to become:

    class EvenHappierCamper
    {
        HappySettings _Settings;

        public EvenHappierCamper(HappySettings useThisSettingsInstance)
        {
            _Settings = useThisSettingsInstance;
        }

        public Int MethodReadingSomeSetting()
        {
            // <snip>
            string LastFolder = _Settings.LastUsedFolder;
            // <snip>
            return Whatever;
        }

        public void MethodWritingSomeSetting(string newValue)
        {
            // <snip>
            _Settings.LastUsedFolder = newValue;
            _Settings.Save();
            // <snip>
        }
    }

Which in turn allows your unit tests to provide EvenHappierCamper with any instance of a HappySettings test descendant that you wish, leaving us with:

Mission accomplished!

You get the benefits of using Properties.Settings.Default without the drawbacks!

Enjoy!

What is the one code practice that has you foaming at the mouth because it cramps your unit testing style? I’d love hearing from you by email or in the comments.

[1] Best practice to save application settings in a Windows Forms Application
[2] Windows Forms User Settings in C#
[3] Application Settings Overview
[4] How do I select a .Net application configuration file from a command line parameter?
[5] Change default app.config at runtime

Posted in Software Development
Tags: , , , ,

Does your code defy you?

Sign up now and receive a regular influx of practical unit testing and software design tips to make your code more testable and improve its design. One small step at a time.
* = required field