Repository navigation
Big Data Marker - #27
Conversation
|
Looks great! I wonder whether we should use the term remotedata rather than bigdata? At this stage there is nothing to say that some small files won't end up online too. @eteq, what do you think? |
|
I agree remotedata is better - I see it more as an aid for people who aren't currently connected to the internet. |
There was a problem hiding this comment.
Maybe this should be from astropy.tests.helper import big_data and then change the below from helper.big_data to just big_data? Presumably some people will look at these tests as an example, and I think just importing the big_data variable is a bit cleaner to read.
Also, it blows my mind a little that you've written tests for the test-running script. Every time I run it now I'll wonder if I'm going to end up in some sort of permanent loop :)
There was a problem hiding this comment.
GitHub needs a +1 button. I love that the tester is tested.
|
remote_data sounds better, I'll put up an update soon. |
|
That was some exciting rebasing, but this should be ready with the remote_data changes. |
There was a problem hiding this comment.
Should this not be assert False? I.e. if the test runs, it should fail, because it shouldn't run, correct? Or does the result of the test depend on whether the remote_data option was specified? My brain hurts...
There was a problem hiding this comment.
My thought was that it should pass if the remote_data option was turned on so that that doesn't result in a scary failure. But you're right that it might be nice if the test failed if it was run without the remote_data option. I was just checking visually that it had been skipped. I'll see what I can do.
|
I've modified the test_skip_remote_data so that it will pass if called from the command line or if |
|
I think this is probably ready to go, but one thing I'm not clear on: By default, do remote_data tests run, or not run? |
|
Oh, although it would be good to update the testing guidelines to include information on this along with the rest of the pull request... I think the testing guideline pull request is almost ready to go, so perhaps you can (re)base it on that once it gets pulled into master? |
|
If you're planning to merge Thomas' testing-guidelines branch soon I'll rebase once that's done and update the docs. |
|
@jiffyclub - we've now merged the testing-guidelines branch, so you can go ahead and update the docs with this pull request. Thanks! |
|
In that case, perhaps we should merge this now and have you update the docs later? |
…a test marking scheme.
…pty string will evaluate to True, which is not the behavior we want.
…mmand line option and for tests marked with @big_data (defined in helper.py) to be skipped unless the --runbigdata option is used. Updated run_tests to work with this new setup.
…ore explicit about what's being skipped and why.
…w not skipped when remote_data=False. Test passes if called from the command line or if remote_data=True.
|
I've just rebased on the astropy master so this should be an easy merge if you want to go for it. And I think it's ready to be merged. Either way I'll get to the docs as soon as I can. |
|
I'm fine with us merging this and adding the docs later. |
Added remote_data marker for tests that use remote data.
|
@jiffyclub Great - once you get back you can issue another pull request to update the guidelines then. Have a good vacation! |
Added remote_data marker for tests that use remote data.
…rm-sky Make frame / SkyCoord transform_to accept SkyCoord object
Add --no-git argument to setup.py, recognized by ah_bootstrap
This pull request implements a scheme for handling tests which should not be run by default.
astropy.tests.helperdefines a marker calledbig_datawhich should be used to mark any test which uses online data.astropy.test()will skip any test marked with@big_dataunless thebig_datakeyword is set to True. (This adds the--runbigdataflag toargsinhelper.run_tests.)If tests are run by using
py.testat the command line in atestsfolder then the decorators will be ignored becausepy.testwill not see the hooks defined inhelper.py. I don't think this should be a problem, though.In the future we can use the same setup for marking tests as slow, or otherwise non-default.
In a tangential change, I changed the
pastebinoption torun_testsso that it only accepts'failed'and'all'as acceptable values (in addition to the defaultNone). Before you could specifypastebin=Truewhich was the same aspastebin='failed'and I didn't like having two options do the same thing. I modified the docstring to make things clear.