Split generic tests into separate package

[Shimuuar]

We have an impressive battery of tests which are generic in vector type. I propose splitting them into separate package to benefit anyone who defines instances for vector type classes (me). It turns out creating nontrivial instance is error prone. I was writing storable vectors with stride (vector elements are every n-th in buffer)

This will entail creating another package vector-test which exposes generic tests and moving vector's test suite there. @lehins @Bodigrim what's you opinion on that?

[Bodigrim]

There are https://hackage.haskell.org/package/quickcheck-classes-0.6.5.0/docs/Test-QuickCheck-Classes.html#v:muvectorLaws, it should be easy to make them more polymorphic to cover Storable.

Cf. https://github.com/Bodigrim/rotcev/blob/master/test/Main.hs

[lehins]

The idea with quickcheck-classes would be problematic:

• The package includes tests for laws, where generic test contains all sorts of good reusable tests that aren't related to any laws. This is mostly conceptional problem and might be not that big of a deal.
• quickcheck-classes depends on vector, so if we move reusable tests into that package, vector itself cannot use it, unless we separate vector tests into its own package. So, we aren't really winning much, still has to create a vector-test package.

I would suggest to create a public sublibrary with reusable tests directly in vector. That comes with nice benefits of having all tests stuff still in vector without a need to start releasing a new package. The downside we'd have to drop support for building cabal < 3.0. As far I've heard hackage has support for sublibraries nowadays, but I haven't confirmed it personally.

Either way, I do see it as a good idea to to expose all the test functionality that could be useful to the outside world and making it reusable through a library, be it standalone or sublibrary.

[Shimuuar]

One benefit of vector's test suite is that it's rather comprehensive. So one could hope that does exercise all relevant properties. It's also more likely to be correct. For example quickcheck-classes do not test tricky part of move. Namely overlapping source/destination.

I like idea of using public sublibrary. It however may break some of existing tooling. Quick search brings up: NixOS/cabal2nix#448 NixOS/cabal2nix#539

[lehins]

It however may break some of existing tooling.

Good. Maybe adding a sublibrary to vector will speed up fixes in those tools. Thus further promoting support for new and useful features 😄

[Bodigrim]

I'd suggest starting with an internal sublibrary first, publishing it and checking how infrastructure copes. Even Stack has (had?) issues with internal sublibraries (see commercialhaskell/stackage#6167) and I suspect that public sublibraries will be an even bigger challenge (see commercialhaskell/stack#5318).