Add file for user-contributed tests

[jodavies]

Collect tests which don't fit in "examples", "features" or "fixes" categories.

These should be fast-running, so they can run as part of the CI.

[jodavies]

At the workshop I would like to persuade people to contribute tests for the FORM CI. This adds a place to collect these. Anything that a user feels is a bit of a "clever" hack for performance, uses "uncommon" features etc, is a good candidate for a test.

So far I added a polyratfun test of my own, and something from @tueda .

[coveralls]

coverage: 49.483% (+0.7%) from 48.788%
when pulling dc32a4e on jodavies:user-tests
into 74735f5 on vermaseren:master.

[tueda]

If I understand correctly, this aims to enhance the variety of regression tests and the code coverage, am I correct? If this is the case, I guess the failure (memory leak) in JD_denexpand was unexpected.

Assuming user-contributed tests will be submitted via GitHub, we might use GitHub account names as prefixes prepended to test names, i.e., jodavies/tueda instead of JD/TU, to ensure uniqueness.

[jodavies]

Yes exactly, the more tests we have the more likely we catch bugs or possible side effects of bug fixes.

Do you think it is better for every test fold to be self-contained, or shall we introduce an include dir under check to keep procedures etc, to clean up the test code?

Indeed this memory leak was unexpected, I am trying to work out what happens there.

[tueda]

In general, I think keeping each test self-contained would be good (which means it can be easily run outside check.rb), but on the other hand frequently used procedures could be put as "standard" testing library (then check.rb must handle its path).

What kind of procedures do you consider?

[jodavies]

I paste in some procedures that I use commonly, for eg in the denexpand test. If these end up being called in more than one test, it would be better to have them in a file which can be included within the test environment.

[tueda]

Indeed, the following code seems to work:

*--#[ tueda_include_test1 :
#include user.frm # tueda_include_test2
.end
assert succeeded?
*--#] tueda_include_test1 :
*--#[ tueda_include_test2 :
#message Hello world!
*--#] tueda_include_test2 :

with

./check/check.rb tueda_include_test1 -v

or

form -I check -D TEST=tueda_include_test1 check/user.frm

So, you can use an extra fold as a library containing procedures etc.

[tueda]

So, ready to merge?

(Perhaps, after the merge, the README file in the check directory should be updated.)

[jodavies]

Yes, I would say so. #507 is somehow independent of the current tests in the file, and can be resolved (or not...) separately.

[tueda]

OK, after merging #522, I will merge this PR (hoping that the code coverage will increase a bit).