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

[NMatrix Open Source]

I may be wrong, but I think this approach won't work because "internal" 
means accessible only from the current assembly (I'm pretty sure). It 
doesn't matter the namespace, AFAIK.
I faced the same problem with other projects, and I only could add the test 
classes inside a #if DEBUG region and put them in the same assembly they 
test. This way, the tests can be called from outside only in debug builds, 
but they can access any internal members of the assembly classes.

Daniel

>From: "Nick Drochak" <ndrochak@gol.com>
>To: "Jonathan Pryor" <jonpryor@vt.edu>, "Mono List" <mono-list@ximian.com>, 
>   "Mono Hackers" <mono-hackers-list@ximian.com>
>Subject: RE: [Mono-hackers-list] Testing .config files
>Date: Sat, 4 Jan 2003 00:23:21 -1000
>
>|  -----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


_________________________________________________________________
Add photos to your e-mail with MSN 8. Get 2 months FREE*. 
http://join.msn.com/?page=features/featuredemail