Hi all, I wanted to point out a couple of things about the new test framework that you should keep in mind if you're writing tests: - Don't use NumpyTestCase any more, just use TestCase (which is available if you do from numpy.testing import *). Using NumpyTestCase now causes a deprecation warning. - Test functions and methods will only be picked up based on name if they begin with "test"; "check_*" will no longer be seen as a test function. I figured I should mention these since there probably hasn't been a general announcement about the testing changes. Thanks, Alan
2008/7/9 Alan McIntyre
- Test functions and methods will only be picked up based on name if they begin with "test"; "check_*" will no longer be seen as a test function.
Is it possible to induce nose to pick these up and, if not actually run them, warn about them? It's not so good to have some tests silently not being run... Anne
On Wed, Jul 9, 2008 at 9:26 AM, Anne Archibald
- Test functions and methods will only be picked up based on name if they begin with "test"; "check_*" will no longer be seen as a test function.
Is it possible to induce nose to pick these up and, if not actually run them, warn about them? It's not so good to have some tests silently not being run...
Having nose pick up "check_" functions as tests may interfere with SciPy testing; it looks like there are a couple dozen functions/methods named that way in the SciPy tree. I didn't look at all of them, though; it could be that some are tests that still need renaming. Since I'm looking at coverage (including test code coverage), any tests that don't get run will be found, at least while I'm working on tests. Still, it might not hurt to have something automated looking for potentially missed tests for 1.2. That would also help with third-party code that depends on NumPy for testing, since they probably don't have the luxury of someone able to spend all their time worrying over test coverage. I can make a pass through all the test_* modules in the source tree under test and post a warning if "def check_" is found in them before handing things over to nose. Anyone else have thoughts on this?
On Wed, Jul 9, 2008 at 14:19, Alan McIntyre
I can make a pass through all the test_* modules in the source tree under test and post a warning if "def check_" is found in them before handing things over to nose. Anyone else have thoughts on this?
I don't think it's worth automating on every run. People can see for themselves if they have any such check_methods() and make the conversion once: nosetests -v --include "check_.*" --exclude "test_.*" -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Wed, Jul 9, 2008 at 14:26, Robert Kern
On Wed, Jul 9, 2008 at 14:19, Alan McIntyre
wrote: I can make a pass through all the test_* modules in the source tree under test and post a warning if "def check_" is found in them before handing things over to nose. Anyone else have thoughts on this?
I don't think it's worth automating on every run. People can see for themselves if they have any such check_methods() and make the conversion once:
nosetests -v --include "check_.*" --exclude "test_.*"
Hmm, could be wrong about that. Let me find the right incantation. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
On Wed, Jul 9, 2008 at 3:26 PM, Robert Kern
I don't think it's worth automating on every run. People can see for themselves if they have any such check_methods() and make the conversion once:
Does this fall into the "how in the world should I have known to do that" category? As long as there's a prominent note in the release notes, either containing such suggestions or links to a page that does, I don't have any problem just including this in the list of things that people should do if they're planning on upgrading to 1.2.
On Wed, Jul 9, 2008 at 14:35, Alan McIntyre
On Wed, Jul 9, 2008 at 3:26 PM, Robert Kern
wrote: I don't think it's worth automating on every run. People can see for themselves if they have any such check_methods() and make the conversion once:
Does this fall into the "how in the world should I have known to do that" category?
Doesn't matter. It doesn't work anyways; those arguments are for matching classes and module-level functions, not TestCase methods. Fortunately, grep works just as well.
As long as there's a prominent note in the release notes, either containing such suggestions or links to a page that does, I don't have any problem just including this in the list of things that people should do if they're planning on upgrading to 1.2.
By all means. This should be documented, of course, but one-time conversion tasks amenable to grep are not worth checking for on every run. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco
participants (3)
-
Alan McIntyre
-
Anne Archibald
-
Robert Kern