[Mono-devel-list] Detecting Mono

Mon Feb 16 17:37:54 EST 2004

Actually, I'm detecting something called "platform" which is some
combination of OS and framework. As the designer of a piece of software,
I may have decided to make use of certain facilities on certain
platforms, other facilities on other platforms. If so, I need to detect
the platforms.

OTOH, if I've decided to dynamically check for the presence of a
feature, the application itself should do that and should recover from
the absence of the feature appropriately. In that case, my tests will
need some moderately complex logic to determine whether they can run in
the environment or not.

I think it all comes down to what works well for the design of a
particular application. 

By the way, your [RequiresFeature("Registry")] can be simulated manually
using the latest Nunit code by using [Category("Registry")] and then
including or excluding that category from the test run.

Charlie Poole
cpoole at pooleconsulting.com

> -----Original Message-----
> From: mono-devel-list-admin at lists.ximian.com 
> [mailto:mono-devel-list-admin at lists.ximian.com] On Behalf Of 
> Ben Maurer
> Sent: Monday, February 16, 2004 2:05 PM
> To: Charlie Poole
> Cc: 'Mono Development'
> Subject: RE: [Mono-devel-list] Detecting Mono
> 
> 
> 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
> 
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com 
> http://lists.ximian.com/mailman/listinfo/mono-> devel-list
> 