C# – How to mock this architecture

cenummocking

This is not a very general question, so it may not exactly be appropriate here, but I could sure use a suggestion if you have one:

I have an object containing a dictionary keyed off of an enum, something like this:

namespace Application
{
    public enum Material { H20, CO2, Na }
    public class Container
    {
        private Dictionary<Material, ChemicalComponent> dic;
        public Container(Dictionary<Material, ChemicalComponent> d)
        {
            dic = d;
        }
    }
}

I now want to create a MockContainer and a MockMaterial, but I can't figure out how to make it all work together. The following code, for example, does not work (see comment):

using Application;  
namespace UnitTesting
{
    public enum mockMaterial { mock1, mock2, mock3 }
    public class mockContainer : Container
    {
        public mockContainer(Dictionary<mockMaterial, ChemicalComponent> d)
            : base(d) // compiler error: the base constructor "has some invalid arguments"
        {
        }
    }
}

Originally I had hoped to extend the Material enum inside the UnitTesting namespace; then I could just use the Container's Dictionary, but with different keys. But of course, that isn't legal in C#. Is there some non-kludgy way to overload or inject a Dictionary with the mock enum keys?

Update: One option is to change the dictionary definition to this:

private Dictionary<Enum, ChemicalComponent> dic;

(i.e., change the key type to Enum throughout the code). This works (i.e., eliminates the compiler error), but this solution sacrifices clarity as well as type-safety. (It is no longer clear what the key is intended to be).

Update #2:
Several people have recommended that I create an interface for Container. But that misses the point. The container itself is not all that complex. But the ChemicalComponents that are stored in it are very complex. I need to mock those in my unit tests, but I don't know how to do that without extending the enum that serves as the key.

Best Answer

I now want to create a MockContainer and a MockMaterial, but I can't figure out how to make it all work together.

Why?

I mean, the purpose of test objects (mocks, fakes, stubs, etc.) are to remove some dependency in your code so you can test while ignoring the dependency. Material is an enum. That's not some sort of dependency that is going to break your tests. Making some inglorious hack is more likely to break your tests (and your production code).

If you want a mock container (I'm assuming your container is more than being an alias to Dictionary<Material, ChemicalComponent>), then you should provide some interface to the container, and mock that.

And remember:

If the code is hard to test, it's probably hard to use (see, lack of interface making it inflexible for a different implementation).
The tests are there to serve you, not vice versa. Don't do things blindly because you should. Do them because they make your life easier.

Related Solutions

Single Responsibility Principle – Avoiding Code Fragmentation

If your class has 20 parameters in the constructor, it doesn't sound like your team quite knows what SRP is. If you have a class that does only one thing, how does it have 20 dependencies? That's like going on a fishing trip and bringing along a fishing pole, tackle box, quilting supplies, bowling ball, nunchucks, flame thrower, etc.... If you need all that to go fishing, you're not just going fishing.

That said, SRP, like most principles out there, can be over-applied. If you create a new class for incrementing integers, then yeah, that may be a single responsibility, but come on. That's ridiculous. We tend to forget that things like the SOLID principles are there for a purpose. SOLID is a means to an end, not an end in itself. The end is maintainability. If you are going to get that granular with the Single Responsibility Principle, it's an indicator that zeal for SOLID has blinded the team to the goal of SOLID.

So, I guess what I'm saying is... The SRP isn't your problem. It's either a misunderstanding of the SRP, or an incredibly granular application of it. Try to get your team to keep the main thing the main thing. And the main thing is maintainability.

Get people to design modules in a way that encourages ease of use. Think of each class as a mini API. Think first, "How would I like to use this class," and then implement it. Don't just think "What does this class need to do." The SRP does have a great tendency to make classes harder to use, if you don't put much thought into usability.

If you're looking for tips on refactoring, you can start doing what you suggested - create coarser-grained classes to wrap several others. Make sure the coarser-grained class is still adhering to the SRP, but on a higher level. Then you have two alternatives:

If the finer-grained classes are no longer used elsewhere in the system, you can gradually pull their implementation into the coarser-grained class and delete them.
Leave the finer-grained classes alone. Perhaps they were designed well and you just needed the wrapper to make them easier to use. I suspect this is the case for much of your project.

When you're finished refactoring (but before committing to the repository), review your work and ask yourself if your refactoring was actually an improvement to maintainability and ease of use.

How to Mock a Method with a Hard-Coded Object

Instead of creating an Employee object directly by using new, your class Bll could use an EmployeeFactory class for this, with a method createInstance, which is injected through the constructor:

 class EmployeeFactory : IEmployeeFactory
 {
       public Employee createInstance(){return new Employee();}
 }

The constructor should take the factory object through an interface IEmployeeFactory, so you can replace the "real" factory it easily by a mock factory.

public class Bll : IBll
{
    private readonly IDal _dal;
    private readonly IEmployeeFactory _employeeFactory;

    public Bll(IDal dal, IEmployeeFactory employeeFactory)
    {
        _dal = dal;
        _employeeFactory=employeeFactory;
    }

    public string GetMessage()
    {
        // Object creating inside business logic method
        // *** using a factory ***
        Employee emp = _employeeFactory.createObject(); 
        // ...
    }
    //...
}

The mock factory can provide the test with any kind of Employee object you need for your test (for example, createInstance could always return the same object):

 class MockEmployeeFactory : IEmployeeFactory
 {
       private Employee _emp;

       public MockEmployeeFactory()
       {
          _emp = new Employee();
          // add any kind of special initializing here for testing purposes
       }

       public Employee createInstance()
       {
          // just for testing, return always the same object
          return _emp;
       }
 }

Now using this mock in your test should do the trick.

Best Answer

Related Solutions

Single Responsibility Principle – Avoiding Code Fragmentation

How to Mock a Method with a Hard-Coded Object

Related Topic