[Mono-devel-list] Detecting Mono

[Ben Maurer]

Well, the problem is that you are not *really* trying to detect the
operating system here.

For example, Mono could be running on Windows, in which case you would
be able to use the registry. You could have it running on PPC, do you
know what to do then? What if we are running on Wine and we decide to
make an interop layer with the windows registry? What if it is running
on Rotor, do you know how to detect that?

By detecting the runtime, you are not getting an answer to the question
you are trying to ask which is `can this operating system do the
registry'.

So rather than seeing:

[Platform ("! Mono")]

I would rather see:

[RequiresFeature ("Registry")]

I realize this takes a little bit of time to maintain, but if you are
maintaining xplatform software, it is probably not that big of an issue
in the scope of things.

I would also encourge something like the `known failures' feature to
keep peole from shoving bugs in the runtime under the rug.

Testing for the platform is really just making a guess about feature
support, which is what it seems you are really asking for. I would
really rather see NUnit provide support for and encourge users to make
use of the real solution, which is to actually test for the features in
question.

-- Ben

On Mon, 2004-02-16 at 16:23, Charlie Poole wrote:
> Ben,
> 
> Following the particular theory of testing you describe, you would
> definitely not have a need for this feature. But some people follow
> other approaches. For example, I like to do TDD and to only write unit
> tests insofar as they are needed to drive the design. After that, I
> focus on acceptance tests. But other folks continue to work at the unit
> test level until they have full "coverage" - in whatever sense it
> matters to them. I could discuss this at greater length, but I'm afraid
> that it's not particularly on topic here.
> 
> Open software like Nunit - or Mono for that matter - needs to satisfy
> the people who use it. Arguments like "Nobody should want this"
> generally lose out in the face of folks who actually have a use for a
> feature, particlarly if one of them is prepared to implement it.
> 
> Charlie Poole
> cpoole at pooleconsulting.com
> 
> > -----Original Message-----
> > From: Ben Maurer [mailto:bmaurer at users.sourceforge.net] 
> > Sent: Monday, February 16, 2004 12:28 PM
> > To: Charlie Poole
> > Cc: Mono Development
> > Subject: RE: [Mono-devel-list] Detecting Mono
> > 
> > 
> > On Mon, 2004-02-16 at 13:57, Charlie Poole wrote:
> > > So - using your example - if an application stored settings 
> > somewhere 
> > > it should have acceptance tests to determine that settings 
> > are saved 
> > > and stored correctly. The test should work whether the 
> > registry or a 
> > > file or some other approach is used to saving the settings.
> > > 
> > > However, the same app would probably have a unit test for it's 
> > > registry access code. That test would only be run in the win32 
> > > environment. If you're not heavily into unit testing and 
> > particulary 
> > > TDD, this may not make sense. However, a large part of the 
> > Nunit user 
> > > community is into those things and so are the developers. :-)
> > 
> > I don't really think that is valid. Tests should probe how 
> > the code works on the *outside* not the inside. For example, 
> > you would not write a test that used Reflection to get the 
> > fields of a class and test if they were set to the right 
> > value. You would use a publicly exposed API. Likewise, you 
> > shouldnt go about probing the storage format of your settings.
> > 
> > Tests really shouldnt assert things about how the code looks inside.
> > 
> > I can see the argument here in a setup where, say, you could 
> > use a MySQL db or a MSSQL db and were expected to interop 
> > with other programs. However, I think that the best way to do 
> > this case is just to build seperate assemblies for each 
> > provider and only run the tests on platforms where the 
> > provider is supported. However, you dont need to change NUnit 
> > to support this.
> > 
> > > Your thoughts on known failures are interesting. It had not 
> > occurred 
> > > to me that there may be a difference between something that doesn't 
> > > work on a platform - and never will - and something that is 
> > expected 
> > > (hoped?) to work some time in the future. For some projects, the 
> > > distinction is not important but it probably is for others. 
> > I'll have 
> > > to think on that.
> > 
> > Actually, I am not thinking of this in terms of platforms, I 
> > am talking about known failures in general. I really dont 
> > like [Ignore] because it makes you *not* run the test.
> > 
> > You could extend this to allowing the decleration of groups by saying:
> > 
> > [Group ("FILED_BUGS")]
> > [Note ("see bug#12345"]
> > ..
> > 
> > And then run on the command line like:
> > 
> > nunit /ignore-group:FILED_BUGS
> > 
> > or you could do:
> > 
> > nunit /known-fail:FILED_BUGS
> > (so maybe you would get a gold star or something if one of 
> > the known failures was made green ;-).
> > 
> > -- Ben
> > 
> > 
> 
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list