[TEST SUITE] description field

Random thought for contemplation …

It might be helpful to also add a ‘description’ or ‘name’ key to the json; e.g.:

“description”: “name: Western Simple.”,

… and maybe also split off a ‘category’ key.

The idea is just to make it easier to generate different groups of
tests and report useful results without having to figure this out from
the file name; for example, maybe I have test functions like:

run_tests(‘name’)
run_tests(‘sorting’)
run_tests(’‘substitution’)

Bruce

Random thought for contemplation …

It might be helpful to also add a ‘description’ or ‘name’ key to the json; e.g.:

“description”: “name: Western Simple.”,

… and maybe also split off a ‘category’ key.

The idea is just to make it easier to generate different groups of
tests and report useful results without having to figure this out from
the file name; for example, maybe I have test functions like:

run_tests(‘name’)
run_tests(‘sorting’)
run_tests(’‘substitution’)

Good idea, all that parsing is annoying, there’s no need for everyone
to repeat it. The filename hints can just be added to the JSON by the
grinder. Will look at this.

It might also be useful to have an optional description field, so that
an application’s test suite can throw up a description of what the
test is about in the event of failure. It would save a little chasing
about in the files to decide where to look for things to fix.

Now is certainly the time to take care of these details, before the
number of tests to refactor swells too much.

Frank

Right, what I’m suggesting is something like “description” and “group.”

Bruce

Good idea, all that parsing is annoying, there’s no need for everyone
to repeat it. The filename hints can just be added to the JSON by the
grinder. Will look at this.

It might also be useful to have an optional description field, so that
an application’s test suite can throw up a description of what the
test is about in the event of failure. It would save a little chasing
about in the files to decide where to look for things to fix.

Right, what I’m suggesting is something like “description” and “group.”

I’ve checked in a version of the script that should check for gsed and
use it if possible, and should add “name” and “category” fields to
the JSON, derived from the filename. Hope it works …

Frank

I’ve checked in a version of the script that should check for gsed and
use it if possible, and should add “name” and “category” fields to
the JSON, derived from the filename. Hope it works …

$ ./grind.sh
whereis: illegal option – b
usage: whereis program […]

Removing he b option allows it to run, but the output is still wrong
(perhaps it’s incorrectly using sed instead of gsed?).

Bruce

Changing the script to this works:

if [ $(which gsed | grep -c “/” ) -gt 0 ]; then
SED="gsed"
else
SED="sed"
fi

echo using $SED

I’ve checked it in; feel free to change as needed of course.

Bruce

Changing the script to this works:

if [ $(which gsed | grep -c “/” ) -gt 0 ]; then
SED="gsed"
else
SED="sed"
fi

echo using $SED

I’ve checked it in; feel free to change as needed of course.

Yowza, a common command at last! Great stuff, it works here too.

The test files themselves contain more clutter than they ought. Many
exercise more than the minimal functionality that they purport to
target, and the data objects contain unnecessary fields, because the
original idea (which didn’t work out so well) was to share them
between tests. Anyone developing is welcome to do tidying up and
rearrangement.

In fact, to signal the shared nature of the archive, this might be a
good time to move it to xbiblio or xbiblio/csl. I’d be happy with
that, if there’s agreement. I seem to remember there’s a
grab-source-from-elsewhere property in svn, I’ll set that on
citeproc-js if the directory goes away.

Frank

In fact, to signal the shared nature of the archive, this might be a
good time to move it to xbiblio or xbiblio/csl. I’d be happy with
that, if there’s agreement.

I was wondering about that too. I don’t have a strong opinion, but
have a hunch that it’d be best as xbiblio/csl/tests.

So, questions:

  1. does that directory make sense, or people prefer to put it at the top-level?

  2. should we retain the same structure, with the generated files
    included in the SVN?

Bruce