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

[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.)

On Sun, Sep 24, 2017 at 8:55 PM, Rob Landley <rob at landley.net> wrote:
> 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
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net



-- 
Elliott Hughes - http://who/enh - http://jessies.org/~enh/
Android native code/tools questions? Mail me/drop by/add me as a reviewer.