nose support

[amleto]

Hi!

I have been tinkering and thinking about how to implement nose unit test support in cricket.  The main difference that I have come across between nose and unittest (I'm not very experienced with either) is that 'free' methods can be unit tests with nose, whereas only class methods can be tests with unittest.

This leads to some ambiguity in the current source because dotted paths are ambiguous.  Consider the hypothetical dotted path:

one.two.three.testMyTest

With nose three could be a class or it could be a module.

I would like to propose that the discover operation returns more than a simple list of strings containing dotted paths ie that the information about the components is also forwarded.

I think this would mean a change in how the discoverer is run - I think it would have to be run in-process.  Currently it is done via subprocess, and the stdout is read.  Is there a reason why this should remain as a subprocess call?

Regards,

amleto

[Russell Keith-Magee]

Hi Tom,

 

Discovery is done via a subprocess mostly for the sake of convenience. Django's test runner provides a convenient entry point, and the process barrier provides an easy point of testing. 

However, there's also a good technical reason (again, mostly Django related) -- the short-running test runner's environment is clearly separated from the long-running environment of Cricket itself. This is particularly important in Django -- if you add a new app to INSTALLED_APPS, this changes the list of tests that will be run. However, Django's settings are cached, so INSTALLED_APPS will be populated on first read. If you run the discoverer a second time, you need to force reload all the settings as well. Doing this in a process makes all this logic simple because each discover run is in a clean process.

I'm not fundamentally opposed to doing this in-process -- but you need to demonstrate that the environment issues can be resolved.

Another approach would be to introduce different syntax for paths -- for example, I've seen colons used to delineate the "module" barrier:

one.two.three:testMyTest 

would be a test method in the three module, but

one.two:three.testMyTest 

would be a test method on the three class, contained in the two module.

The model classes already make a distinction between a test Class and a test Module, but the discovery process is a bit naive about the distinction (it's assumed that the 'leaves' are all test methods, contained in classes, contained in modules). If you had a richer language for describing the module barrier, I suspect this naiveté could be resolved.

Yours,

Russ Magee %-)