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

[Jonathan Pryor]

An internal member (field, property, etc.) can be accessed from any
class within the same *assembly*, NOT the same namespace.  So even if
the NUnit tests had a System.Diagnostics namespace, they couldn't access
the internal DiagnosticsConfiguration class as they'd be within a
different assembly.

I have no desire to make DiagnosticsConfiguration public so that it can
be accessed from outside its assembly, as .NET doesn't appear to have
any such public class, either.

You are correct that reading actual config files is not the
responsibility of the TraceSwitch tests.  I would argue, however,  that
it makes a good location to test some of the handling of config file
handling.  Especially since the interaction between
System.Configuration.ConfigurationSettings and
System.Diagnostics.DiagnosticsConfigurationHandler must be tested
somewhere.  The TraceSwitch test seems like an excellent location to
handle this interaction.

In some respects I'm torn.  On the one hand, it's nice to be able to
test the internals of a class.  On the other hand, the public interface
and the "normal" means of using that interface must also be tested.  The
current Switch design prohibits simple testing of the former while
requiring the latter.

Gonzalo's approach of using AppDomains would permit testing.  If we just
want to test the Switch classes (not their interaction with the
configuration file), I suppose we could use reflection to change the
IDictionary object returned by the DiagnosticsConfiguration.Settings. 
I'm not sure if using reflection for this is desirable, though, as it
ties the test case to the Mono implementation (preventing the test case
from being used under .NET and complicating future maintenance of the
code.).

At present, I believe that using AppDomains is the superior solution,
considering that the higher-level interactions need to be tested and
that portability with .NET should be maintained.  It may be heavyweight,
but it would work.

 - Jon

On Sat, 2003-01-04 at 05:23, Nick Drochak wrote:
> |  -----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.
> 
> 
> _______________________________________________
> Mono-hackers-list maillist  -  Mono-hackers-list@ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-hackers-list