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.
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.