Skip to content

Conversation

@marqh
Copy link
Member

@marqh marqh commented Sep 12, 2016

remove graphic tests in favour of numerical tests for testing other parts of the code base

assertCML (where already in use) is left as sufficient test coverage

otherwise, data operations are tested using statistics of the data array

@marqh
Copy link
Member Author

marqh commented Sep 12, 2016

interestingly, given my aim to reduce version dependency, there are 4 numerical check failures, compared to a local platform (where all these pass) which tries to mimick the travis environment

@marqh marqh mentioned this pull request Sep 12, 2016
res = regrid_area_weighted(src, dest)
qplt.pcolormesh(res)
self.check_graphic()
self.assertArrayAlmostEqual(res.data.mean(), 280.137698)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Here and elsewhere you're using assertArrayAlmostEqual for scalars.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of interest, why have you used 'AlmostEqual', rather than 'Equal'?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Out of interest, why have you used 'AlmostEqual', rather than 'Equal'?

because every time someone compares two floats for equality in a test, a fairy dies ;)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So it's a precision issue? In that case, maybe a hash of data would be better to test. NumPy arrays can't be hashed, but the underyling buffer (ndarray.data) can be, if the writeable flag of the ndarray is set to False.

I'm wondering if testing the mean/standard deviation means we wouldn't catch bugs which only changed the data slightly. It's probably nothing to worry about, but just a thought.

@DPeterK
Copy link
Member

DPeterK commented Sep 13, 2016

👍 for removing extraneous graphics tests!

Some thoughts on the strategy proposed here...

  • There are still a number of cases of testing for CML equality. This will of course be open to the same issues in many ways as the graphics tests: a small change in the CML leads straight to a test failure.
  • I like the approach of checking for near equality of mean & stdev of the data arrays, but I wonder whether these provide enough information to test equality of the two data arrays?
  • What this of course means is that we need a different approach for equality testing. As has been discussed, for graphics tests we could check that multiple items of the two matplotlib graphics (e.g. the extents of the x and y axes, presence of colorbar, ...) are equal or near-equal.

'201007020900_u1096_ng_ey00_visibility0180_screen_2km'))
self.src = iris.load_cube(path)[0]
self.src.data = self.src.data.astype(np.float32)
self.src.data = self.src.data.astype(np.float64)
Copy link
Member

@bjlittle bjlittle Sep 13, 2016

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marqh Is this up-casting to avoid numpy 1.8 issues?

If so, would you agree a comment might be handy? As for line +76 ...

@bjlittle bjlittle self-assigned this Sep 15, 2016
plt.contourf(res.coord('grid_longitude').points,
res.coord('grid_latitude').points,
res.coord('surface_altitude').points)
self.check_graphic()
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marqh Nice. If we have assertCML coverage then there's no need for check_graphic coverage as well.

Copy link
Member

@bjlittle bjlittle left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marqh I agree with the pattern to purge the use of check_graphic in a unit test when it already performs an assertCML.

In all of the other cases, where check_graphic is purged and a new statistical check is now performed in it's place i.e. a tolerance on the mean and std of the data payload - I'd like to see this common pattern sprinkled throughout the code available as a new assert method within the iris.tests.IrisTest class:

  • it can easily be parameterised
  • also allows us to easily add more statistical checks or rigor, if we want, into the new assert method, and this is applied consistently within all relevant unit tests.

I'm happy with this approach. Do other @SciTools/iris-devs have an opinion?

@marqh
Copy link
Member Author

marqh commented Sep 15, 2016

@bjlittle I understand, this seems like a useful pattern.

I have implemented assertArrayShapeStats for IrisTest

@DPeterK
Copy link
Member

DPeterK commented Sep 15, 2016

@bjlittle @marqh like it! 👍

@bjlittle
Copy link
Member

@marqh LGTM 👍

@bjlittle bjlittle merged commit b2b46b1 into SciTools:master Sep 15, 2016
@QuLogic QuLogic added this to the v2.0 milestone Sep 15, 2016
@QuLogic
Copy link
Member

QuLogic commented Sep 15, 2016

near equality of mean & stdev of the data arrays, but I wonder whether these provide enough information to test equality of the two data arrays?

Anscombe's quartet says no.

djkirkham added a commit to djkirkham/iris that referenced this pull request Sep 19, 2016
@pelson pelson mentioned this pull request Oct 7, 2016
@QuLogic QuLogic modified the milestones: v2.0, v1.11 Oct 7, 2016
@QuLogic QuLogic modified the milestones: v1.11, v2.0 Oct 7, 2016
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.

5 participants