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" <[EMAIL PROTECTED]>
To: "Jonathan Pryor" <[EMAIL PROTECTED]>, "Mono List" <[EMAIL PROTECTED]>, "Mono Hackers" <[EMAIL PROTECTED]>
Subject: RE: [Mono-hackers-list] Testing .config files
Date: Sat, 4 Jan 2003 00:23:21 -1000
| -----Original Message-----
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED]]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 - [EMAIL PROTECTED]
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
_______________________________________________
Mono-list maillist - [EMAIL PROTECTED]
http://lists.ximian.com/mailman/listinfo/mono-list
