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: [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 _______________________________________________ Mono-list maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/mono-list
