Creating ConfigurationSections can be tricky but it’s quite straightforward to test them, provided you take care and don’t try to do too much like this subtle bug in MvcContrib.IncludeHandling that lead me crazy for a couple of hours.
NOTE: I sent a pull request that was accepted and the bug is fixed in these two commits: 6c654a152d8d and 0368c6094f2b.
The thing is that the code does like this:
public IncludeHandlingSectionHandler()
{
_types = new Dictionary<IncludeType, IIncludeTypeSettings>
{
{ IncludeType.Css, Css },
{ IncludeType.Js, Js }
};
}Where this is the constructor and .Css and .Js properties are marked with ConfigurationProperty, so in theory seems correct.
In the tests, there’s an XML file with the section and it’s loaded using the DeserializeSection method of the ConfigurationSection base class. And this seems correct, everything goes ok and the dictionary is populated correctly with the data from the XML file.
But it’s wrong. If you add the section to the app.config (or web.config) file and instead of using DeserializeSection you use ConfigurationManager.GetSection(sectionName), the constructor is called before populating the Css and Js properties so the dictionary is not created properly but as those properties return a default implementation in case there’s no configuration, it seems to work, but the configured values are never loaded.
This way, tests pass but it’s impossible to configure the library via web.config. Anyway, in my opinion the problem is in .NET Framework because internally, GetSection should use DeserializeSection to be consistent.
