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 <r...@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@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. _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net
