test: get rid of ring_to_mat

[fingolfin]

The 'similar' methods being tested are generic and defined &
tested in AA.

Getting rid of this makes it somewhat less annoying to run the
affect test files interactively.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.10%. Comparing base (542a6be) to head (d0eaf8e).
Report is 1 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1902      +/-   ##
==========================================
- Coverage   88.14%   88.10%   -0.05%     
==========================================
  Files         100      100              
  Lines       36852    36852              
==========================================
- Hits        32482    32467      -15     
- Misses       4370     4385      +15     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[lgoettgens]

I agree that currently these tests are more or less useless. But these would make it very easy to test #1826 (once that is fixed) by just adding @test t isa M twice in each of the for-loops.

[fingolfin]

Sure, but I think this should be handled by adding such a test to the ring conformance tests in AA.

[fingolfin]

To move forward for this, my solution would be to integrate a similar test into the conformance test suite. Specifically into test_MatSpace_interface.

To handle conversion to different rings, we could use something similar to the adhoc_partner_rings to provide a list of "partner" rings against which to perform the similar tests. Note that M should be redundant and just the same as dense_matrix_type(R).

[fingolfin]

I believe this could be merged now...

[lgoettgens]

To move forward for this, my solution would be to integrate a similar test into the conformance test suite. Specifically into test_MatSpace_interface.

What about first adding that there and then removing it here afterwards? Otherwise, we just reduce code coverage for little benefit

[fingolfin]

What about first adding that there and then removing it here afterwards? Otherwise, we just reduce code coverage for little benefit

That was already done last November, see Nemocas/AbstractAlgebra.jl#1890

[fingolfin]

Oh no, wait, those are not for conversion to other rings. sigh

[fingolfin]

Alas, I am not sure how to generically implement this then. It seems we'd need a global list of "example ring objects" for this ?

[lgoettgens]

Alas, I am not sure how to generically implement this then. It seems we'd need a global list of "example ring objects" for this ?

It seems so. And this list ist what this PR is removing 😅
Maybe one could do something similar as for the adhoc_partner_rings, see https://github.com/Nemocas/AbstractAlgebra.jl/blob/7fcf80bf8aa1f39ae11dfc5b921a48c37dd2d252/src/ConformanceTests.jl#L33