Dan Kegel dank@kegel.com writes:
The current cmd test framework is not currently clever about resyncing after an error, so any missing or extra line in a test's output can cascade and cause lots of false reports.
How about one file for each command recognized by cmd? So there'd be test_if.cmd (which might cover else as well), test_goto.cmd, etc. That feels more manageable to a test writer, I suspect. The only problem is that pesky .rc file; it'd be nice to autogenerate it. I can submit a patch to do that, but you rejected that last time, probably because dependencies were not handled perfectly. Would a patch that generated the .rc file be accepted if it got dependencies perfect?
Maybe, but you still need to maintain the list of files somewhere. And in any case it doesn't change the fact that the number of files must be kept small. If the test program is not clever enough to manage large files it should be fixed.
For the day when our test files get long (some commands are going to have lots of options), it will make the result parser's job a lot easier to have unique-ish begin and end tags in the output. Bug ID is as good as anything for a unique ID when it's available. Maybe I can make that clearer, e.g.
echo begin bug21382 rem meaningful description of this test goes here ... echo end bug21382
OK?
No, that's just noise. Simply output the description instead of outputting a random id and hiding the description in a comment.