[Mono-list] RE: [Mono-hackers-list] Testing .config files

[Nick Drochak]

|  -----Original Message-----
|  From: mono-hackers-list-admin@ximian.com
|  [mailto:mono-hackers-list-admin@ximian.com]On Behalf Of Jonathan Pryor
|  Sent: Friday, December 20, 2002 10:37 AM
|  To: Mono List; Mono Hackers
|  Subject: [Mono-hackers-list] Testing .config files
|
|
|  While trying to write test cases for TraceSwitch's, I ran across an
|  issue I had asked about before (on December 12)...and received no
|  response.  Here's hoping that a second plea will help.
|
|  Does anybody have any ideas on how to test the behavior/handling of
|  application .config files?
|

Hi Jonathan,

I'm on vacation right now, and can't try it myself, but here's my ideas
which come from basic unit testing methodogies:

1) The problem lies in the design (as implemented) of the Switch class.  It
uses a DiagnosticsConfiguration class to get the setting value, which in
turn probably opens and reads a file. If it were possible to specify at
runtime which class to use to get the value, then any IDictionary would do.
For example, if we add an internal property "Dictionary" to Switch to hold
an IDictionary then GetConfigFileSetting() would use that property instead
of the "d" variable it currently uses.  We could set the initial value of
Dictionary to DiagnosticsConfiguration.Settings ["switches"]. I beleive an
internal property can be accessed by any other class in the same namespace?

2) If so, the unit test class's namespace could be "System.Diagnostics" so
that it could change the value of the TraceSwitch's internal Dictionary
property (which it inherited from Switch).  We would use a "mock" settings
dictionary object that we could pre-load with the values we want it to
provide to TraceSwitch.

This avoids the problem completely of reading acutal config files, which is
not really the responsibility of TraceSwitch anyway.  We just want to check
a that those boolean properties behave correctly, etc. It also avoids nasty
AppDomain stuff, which is really overkill for this simple unit test also.

If you want more ideas on this "mock object" testing pattern or other info
on unit testing in general, check out www.junit.org.

I'll try some of this when I get back from vacation if you don't get a
chance to, or if I've been completely incomprehensible :)

Regards,
Nick D.