[Toybox] Release prep and testcmd in tests/*.test

[Rob Landley]

Three months from last release was the 15th, and I've let it slip a
little but should definitely get the next release out by the end of the
month. So, trying to tie some things off and check them in.

One local diff I've got in my tree is I introduced the "testcmd" shell
function to the test suite a while back, and was slowly converting
things over, but I'm having second thoughts about it.

The rationale is some commands are shell builtins, so if you just naive
ly test "echo blah" it's not actually gonna call the one out of the
$PATH, so you're not testing what you think you are.

First I added a $C environment variable that's an absolute path to the
command binary to test, but you need to quote it to use it properly
because your path might have spaces in it. And if people add tests in an
environment that doesn't have spaces in the path you extracted the
toybox source into, it'll work fine and then break for somebody else
later. (Whee!)

So I added a "testcmd" function that starts your command line with "$C"
and a space, so that instead of:

testing "name" "command arguments" "output" "inputfile" "stdin"

You just do

testcmd "name" "arguments" "output" "inputfile" "stdin"

The problem is some tests (such as the blkid ones) don't _start_ with
the command name, but pipe the output of another command into stdin (in
this case bzcat filename). So those still need to be "testing", not
"testcmd", and I don't like having BOTH.

I want this to be simple, and reality isn't cooperating. I'm not sure
which is better:

1) Back out testcmd and use "$C" as needed. Advantage: one consistent
syntax. Downside: spaces in pathnames if improperly quoted, will use
shell builtin and _seem_ to work if you just use the name (but only
sometimes, mostly that'll work too), lots of redundant "$C" expressed
over and over without really needing to be.

2) Use testcmd where I can, and testing where I can't. Downside: two
syntaxes being nonobviously different.

Sigh. Maybe testcmd should have a different name? I don't want it to be
significantly longer name because that leads to more wrapped lines.)

This is another one of those "it's close enough there isn't an obvious
solution". This is how academia winds up with endless squabbles over
trivia, if there was a big difference it would be easily solvable. :P

Rob

[enh]

say what you like about all the perl
(https://android.googlesource.com/platform/external/mksh/+/master/src/check.pl),
there's a lot to be said for the style it lets mksh tests be written
in (https://android.googlesource.com/platform/external/mksh/+/master/src/check.t).
it's inherently self-documenting, breaks well across multiple lines,
lends itself perfectly to supporting optional sections, and it's easy
to come back to a test after a long time and see at a glance what the
parts are without having to read the source.

i didn't really see any significant difference between
testing/testcmd, other than testcmd making it impossible to forget to
include the command name in the human-readable string.

(though obviously i don't personally encourage having thousands of
tests all in just a single file.)

Post by Rob Landley
Three months from last release was the 15th, and I've let it slip a
little but should definitely get the next release out by the end of the
month. So, trying to tie some things off and check them in.
One local diff I've got in my tree is I introduced the "testcmd" shell
function to the test suite a while back, and was slowly converting
things over, but I'm having second thoughts about it.
The rationale is some commands are shell builtins, so if you just naive
ly test "echo blah" it's not actually gonna call the one out of the
$PATH, so you're not testing what you think you are.
First I added a $C environment variable that's an absolute path to the
command binary to test, but you need to quote it to use it properly
because your path might have spaces in it. And if people add tests in an
environment that doesn't have spaces in the path you extracted the
toybox source into, it'll work fine and then break for somebody else
later. (Whee!)
So I added a "testcmd" function that starts your command line with "$C"
testing "name" "command arguments" "output" "inputfile" "stdin"
You just do
testcmd "name" "arguments" "output" "inputfile" "stdin"
The problem is some tests (such as the blkid ones) don't _start_ with
the command name, but pipe the output of another command into stdin (in
this case bzcat filename). So those still need to be "testing", not
"testcmd", and I don't like having BOTH.
I want this to be simple, and reality isn't cooperating. I'm not sure
1) Back out testcmd and use "$C" as needed. Advantage: one consistent
syntax. Downside: spaces in pathnames if improperly quoted, will use
shell builtin and _seem_ to work if you just use the name (but only
sometimes, mostly that'll work too), lots of redundant "$C" expressed
over and over without really needing to be.
2) Use testcmd where I can, and testing where I can't. Downside: two
syntaxes being nonobviously different.
Sigh. Maybe testcmd should have a different name? I don't want it to be
significantly longer name because that leads to more wrapped lines.)
This is another one of those "it's close enough there isn't an obvious
solution". This is how academia winds up with endless squabbles over
trivia, if there was a big difference it would be easily solvable. :P
Rob
_______________________________________________
Toybox mailing list
http://lists.landley.net/listinfo.cgi/toybox-landley.net