Implement generic testing from #6343 for matrices

[jasongrout]

The patch calls TestSuite().run() every time load(dumps()) was called in the matrix directory. I also renamed and adapted an existing _test_pickle() into _test_reduce().

CC: @kcrisman @nthiery @hivert @rbeezer

Component: linear algebra

Keywords: TestSuite

Author: Jason Grout

Reviewer: Nicolas M. Thiéry

Merged: sage-4.3.1.rc1

Issue created by migration from https://trac.sagemath.org/ticket/6936

[jasongrout]

comment:2

This, of course, depends on the patches at #6343.

[kcrisman]

comment:4

Ticket #6934 is related, of course.

[nthiery]

Changed keywords from none to TestSuite

[nthiery]

Reviewer: Nicolas M. Thiéry

[nthiery]

comment:5

Hi Jason,

I am glad to hear that TestSuite is useful, even before the category
code gets in :-)

Some suggestions:

• remove the loads(dumps(a)) == a tests, since anyway they are
  done by TestSuite

• Maybe rename _test_matrix_pickle by _test_reduce?

  In fact, it would be nice to have this test whenever __reduce__ is
  implemented (even though it's tested by test_pickle anyway). An
  option would be to lift _test_reduce to SageObject, and add a
  conditional in _test_reduce to do nothing if _reduce_ is not
  defined. The downside is that, if someone inadvertently remove
  __reduce__, then this won't be detected. Any better idea?

• About _test_minpoly (and in general _test methods for elements):
  One thing which is not yet clear to me is whether the _test method
  should be on the elements or the parent. The former sounds more
  natural; however, with the later, one can use the information from
  the parent to build a good set of elements on which to run the
  test.

  One option would be to add to each parent a method _test_elements
  that would run TestSuite on some_elements(). However, there
  typically might be very expensive test methods that one will want
  to run on just a couple small elements, and other test methods that
  one will want to test with many large ones.

  But that's just food for thoughts for the long run

Other than that, I will be very happy being a reviewer for this patch,
and put a positive review.

I haven't run the tests yet. But from the comments above, I gather
that some tests are broken, not because this patch is wrong, but
because it uncovers bugs elsewhere. Should those be fixed before
setting a positive review on this one?

[jasongrout]

comment:7

Replying to @nthiery:

Hi Jason,

I am glad to hear that TestSuite is useful, even before the category
code gets in :-)

Some suggestions:

• remove the loads(dumps(a)) == a tests, since anyway they are
  done by TestSuite

The -review.patch patch does this.

• Maybe rename _test_matrix_pickle by _test_reduce?

The -review.patch patch does this.

In fact, it would be nice to have this test whenever __reduce__ is
implemented (even though it's tested by test_pickle anyway). An
option would be to lift _test_reduce to SageObject, and add a
conditional in _test_reduce to do nothing if _reduce_ is not
defined. The downside is that, if someone inadvertently remove
__reduce__, then this won't be detected. Any better idea?

• About _test_minpoly (and in general _test methods for elements):
  One thing which is not yet clear to me is whether the _test method
  should be on the elements or the parent. The former sounds more
  natural; however, with the later, one can use the information from
  the parent to build a good set of elements on which to run the
  test.

  One option would be to add to each parent a method _test_elements
  that would run TestSuite on some_elements(). However, there
  typically might be very expensive test methods that one will want
  to run on just a couple small elements, and other test methods that
  one will want to test with many large ones.

  But that's just food for thoughts for the long run

The rest of these items sound controversial enough that they should be brought up on sage-devel.

Other than that, I will be very happy being a reviewer for this patch,
and put a positive review.

If you're happy with the changes, can you mark this positive review?

I haven't run the tests yet. But from the comments above, I gather
that some tests are broken, not because this patch is wrong, but
because it uncovers bugs elsewhere. Should those be fixed before
setting a positive review on this one?

I'd say merge this, since it uncovers existing bugs, but doesn't introduce any. With this merged, those bugs will get fixed before the next release.