Question

I have a class with a construct like this:

private static Dictionary<Contract, IPriceHistoryManager> _historyManagers = new Dictionary<Contract, IPriceHistoryManager>();

and lets say 2 methods like:

 public void AddSth()
 {
    _historManagers.Add(new Contract(), new PriceHistoryManager());
 }

 public int CountDic()
 {
    return _historyManagers.Count(); 
 }

Problem:
When running unittests there is no way to “reset” the Dictionary and when i create multiple unittests with seperate instances of the class, then “CountDic” gives unpredictable results and i can’t test the listentries.

Question:
Is this generally considered a “bad” approach and if yes: how to do it better/more unittestable?
And if not: How to unittest this best?

Thx.

Answer 1

Don’t be afraid to expose public operations for testing purposes. Paraphrased from “The Art of Unit Testing” by Roy Osherove: When Toyota builds a car, there are testing points available. When Intel builds a chip, there are testing points available. There are interfaces to the car or chip that exist only for testing. Why don’t we do the same for software? Would a ResetHistory() method completely destroy your API?

If that answer is yes, then create the method, but make the method internal. You can then use the assembly InternalsVisibleTo to expose the guts to your unit test library. You have a method available to you created 100% for testing, but there’s no change to your public API.