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.

  • Why do you have string in Container constructor? dic = d; shouldn't be compilable with the types you have. – Euphoric Oct 17 '14 at 20:43
  • @Euphoric: typo; fixed – kmote Oct 17 '14 at 20:45
  • 1
    Do you want to ensure the material is only one of few predefined values, or do you want it to be possible to define your own material? Both pieces of your code conflict in those ideas. You have to make up your mind. – Euphoric Oct 17 '14 at 20:46
  • 7
    Laugh at it. Oh, wait. – Robert Harvey Oct 17 '14 at 20:50
  • 2
    Seems to me that mock frameworks generally work because the class-that-is-to-be-laughed-at implements an interface and your code uses that-interface-type references. And I don't see why both key and value objects must be mocked. And if enums are essentially compile-time constants of integers then mocking it seems pointless (you really can't hurt an enums feelings). BUT in C# you can get away with casting an invalid value to that enum-type – radarbob Oct 17 '14 at 21:23

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


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.
  • It's not some "dependency" I want to ignore in this case, it's "complexity". The actual Materials in this Container have complex physical characteristics (e.g., atomic weight, specific gravity, etc). For my tests, I want to "invent" arbitrarily simple materials (i.e., "fake" elements, so to speak, with manually selected physical values that are chosen to test boundary conditions and so on). And, btw, I'm looking for a solution precisely because it will make my life simpler. – kmote Nov 17 '14 at 15:56
  • 2
    @kmote - perhaps I'm missing something then. "Complex physical characteristics" is still just a bundle of data. Spin up a new object with your test data, insert into dictionary, test. It doesn't much matter if you're providing entirely incorrect data for water - the key is meaningless. If there's more logic in the characteristic class (ChemicalComponent?) then give it an interface you can mock. – Telastyn Nov 17 '14 at 17:05
  • @Telastyn:Your comment IS THE ANSWER. I think your post sort of says the same thing but isn't as clear as your comment. – Dunk Nov 17 '14 at 19:30
  • Perhaps I'm missing something but "insert into dictionary" is precisely the step that I can't figure out how to do. I can't just alter the characteristics of H2O because (1) I need a naming convention to identify the unique characteristics of each Mock Component (otherwise it would be terribly confusing to maintain the tests), and (2) I still want to test H2O (and CO2, and Na, etc) so I can't just arbitrarily change their characteristics for the tests. – kmote Nov 17 '14 at 21:00
  • @kmote - (1) I don't know what you're doing, but each test should have 1 or a few components at most. Labeling them shouldn't be that confusing. This may be a sign that they shouldn't be enums. (What happens when someone wants to use H2O2?). (2) Each test should have its own instance of the dictionary, so water in one test can be different than water in another. If this isn't clear/helpful, you might need to provide a more concrete example of what's going on, because what you're saying isn't lining up with the code. – Telastyn Nov 17 '14 at 21:07

You could make Container a generic class with one type parameter, constrained to be an enum.

Your mock couldn't subclass that way, so you would need to make an interface.


Its not worthwhile to mock away an enum, you gain nothing by it. You wouldn't mock away System.Int32 would you? As far as mocking container, I'd create an interface and then you can mock the implementation of that interface.

  • I wouldn't mock away Int32 because it is already a simple value. In my case, the enums are functioning as keys which "point" to specific complex data structures. For my tests, I want to be able to point to simplified data structures. So it is not the Container that needs an interface so much, as the ChemicalComponents within the Container – kmote Nov 17 '14 at 16:02
  • @kmote Enums are just ints though as well. You can do this legally Material x = (Material)35353; The point is enums have no behavior; I doubt you'd mock strings or List<T> either. – Andy Nov 18 '14 at 23:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.