Which packages do not have default tests

[olexandr-konovalov]

Using the script from https://github.com/gap-system/gap-distribution/blob/master/DistributionUpdate/PackageUpdate/healthcheck.g, one can produce a package healthcheck report (see gap-system/gap-distribution#49 for a most recent one).

Below is the list of packages from GAP 4.10.1 distribution without the test file specified in their PackageInfo.g file. GAP 4.10.1 has 110 packages with such test, and 35 packages without it.

Why these tests are useful? Because they provide a way to test whether the package is still usable, and that changes introduced in GAP and in other GAP packages do not break your package. While we aim to have comprehensive tests covering most of the package code (see https://codecov.io/gh/gap-packages?sort=coverage&order=desc), even a basic test of some of the package functionality is better than no test at all. These tests are run regularly, even when your package is not in active development, and may be run at different stages:

• for official package releases
• for development versions of packages
• for each commit and pull request made to a package

Here is the TODO list, with pings to some package authors.

• browse - @frankluebeck @ThomasBreuer
• corelg - @heikodietrich @willemdegraaf
• design - @lhsoicher
• edim - @frankluebeck
• fwtree (https://github.com/gap-packages/fwtree)
• gapdoc - @frankluebeck
• itc (maintainer - The GAP team) (tests make no sense, this is a graphics package)
• liering - @willemdegraaf
• nilmat
• polymakeinterface - @sebasguts
• quagroup - @willemdegraaf
• sla - @willemdegraaf
• symbcompcc (maintainer - The GAP team)
• xgap - @fingolfin (tests make no sense, this is a graphics package)

CAP project: https://github.com/homalg-project/CAP_project

• cap - @sebasguts @oysteins
• generalizedmorphismsforcap - @sebasguts @sebastianpos
• linearalgebraforcap - @sebasguts @mohamed-barakat
• modulepresentationsforcap - @sebasguts @sebastianpos

Homalg project and associates: https://github.com/homalg-project/homalg_project/

• 4ti2interface - @sebasguts
• convex - @sebasguts
• examplesforhomalg - @mohamed-barakat
• gauss - @mohamed-barakat @sebasguts
• gaussforhomalg - @mohamed-barakat
• gradedmodules - @mohamed-barakat @sebasguts
• gradedringforhomalg - @mohamed-barakat @sebasguts
• homalg - @mohamed-barakat @sebasguts
• homalgtocas - @mohamed-barakat @sebasguts
• io_forhomalg - @mohamed-barakat @sebasguts
• localizeringforhomalg - @mohamed-barakat
• matricesforhomalg - @mohamed-barakat
• modules - @mohamed-barakat @sebasguts
• ringsforhomalg - @mohamed-barakat
• sco - @mohamed-barakat
• toolsforhomalg - @sebasguts @mohamed-barakat
• toricvarieties - @sebasguts

[mohamed-barakat]

Dear Alexander, most of my packages do have a make test. Shall I simply call this in tst/testall.g?

[olexandr-konovalov]

@mohamed-barakat you can not call make test there, it should be a .tst file or (preferably) a GAP input file that looks like https://github.com/gap-packages/example/blob/master/tst/testall.g and usually checks all test files in the tst directory.

I looked at https://github.com/homalg-project/homalg_project/blob/master/Modules/maketest.g and its make test target. I would prefer to avoid rebuilding the manuals, so if I only read maketest.g without make doc (for a released version of the package), that may actually work. I will test and maybe adjust maketest.g a bit for better test failure detection. Would Modules be a good place to try?

[mohamed-barakat]

Thank you for your answer. And yes, Modules would be a good place to try.

[olexandr-konovalov]

@mohamed-barakat please see homalg-project/homalg_project#233 which adapts maketest.g from Modules to work both for the make test target and for the tests from the GAP test suite.

[olexandr-konovalov]

Ticked boxes for DESIGN and EDIM. Thanks @lhsoicher and @frankluebeck