Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

g1 rule update #221

Merged
merged 3 commits into from
Dec 20, 2012
Merged

g1 rule update #221

merged 3 commits into from
Dec 20, 2012

Conversation

bblay
Copy link
Contributor

@bblay bblay commented Nov 23, 2012

No description provided.

@bblay
Copy link
Contributor Author

bblay commented Nov 23, 2012

Closing for now, until tests are added.

@bblay bblay closed this Nov 23, 2012
@bblay bblay reopened this Nov 27, 2012
@bblay
Copy link
Contributor Author

bblay commented Nov 27, 2012

Re-opened for discussion (or just to merge?!).

I don't think we can use mocking for this.
The rules are all lumped together so we'd have to mock almost an entire grib message,
in order for it to pass through all the load rules.

If the rules were atomic python functions, like in grib_save,
we could just test one specific rule, as I've tried to do in #229.

I'm happy to be proved wrong.
Can anyone suggest how we might test just this one rule?

@rhattersley
Copy link
Member

I can't see a sane way to only run one rule. But I don't think you really want to do that anyway. Testing a single if statement isn't much use to anyone. You want to test the related statements at the same time to make sure they aren't treading on each other's toes. (In other words, if the rules were expressed as functions then you wouldn't have a function for each rule, you'd have a function for each logical group of rules.)

That said, it doesn't look like it'd be that hard to run all the rules with a minimal mock grib message and check for a simple Cube with the relevant long_name. Most of the rules are "opt-in" rules, where a dumb mock object wouldn't pass the tests.

For example:

IF
grib.gridType=="regular_ll"
grib.jPointsAreConsecutive == 0
THEN
...

This wouldn't trigger as grib.gridType would return another Mock object, which wouldn't compare equal to "regular_ll".

For the very few "opt-out" rules, I'd probably just add attribute to the mock grib message which prevent them from triggering.

@bblay
Copy link
Contributor Author

bblay commented Nov 29, 2012

Thanks, excellent guidance @rhattersley, this works very nicely.

@bblay
Copy link
Contributor Author

bblay commented Dec 6, 2012

rebased

@bblay bblay mentioned this pull request Dec 7, 2012
@bblay
Copy link
Contributor Author

bblay commented Dec 20, 2012

Anyone want to pick this up for Bernd?
https://groups.google.com/forum/#!topic/scitools-iris/qjvJyXp6JGc

@rhattersley
Copy link
Member

@bblay - this PR currently needs a rebase - so it'd be best to get that done before going over the code again.

@ghost ghost assigned rhattersley Dec 20, 2012
@bblay
Copy link
Contributor Author

bblay commented Dec 20, 2012

Rebased. Tests no longer working.

======================================================================
ERROR: test_table1_localparam (__main__.TestGribLoadRules)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "test_grib_load.py", line 57, in test_table1_localparam
    iris.fileformats.grib._load_rules.verify(cube, grib)
  File "/home/h05/itbb/.local/lib/python2.7/site-packages/iris/fileformats/rules.py", line 602, in verify
    rule_factories = rule.run_actions(cube, field)
  File "/home/h05/itbb/.local/lib/python2.7/site-packages/iris/fileformats/rules.py", line 391, in run_actions
    raise err
TypeError: %d format: a number is required, not Mock

@bblay bblay mentioned this pull request Dec 20, 2012
rhattersley added a commit that referenced this pull request Dec 20, 2012
@rhattersley rhattersley merged commit 66c670f into SciTools:master Dec 20, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants