On Fri, Feb 12, 2010 at 1:55 AM, Alexandre Julliard <julli...@winehq.org> wrote: > Please don't create new files for every small test, this will become > unmanageable very quickly. Unless there are reasons to split them, > everything should go in a single .cmd file.
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? >> +echo Begin test for bug 21382 >> +rem On old wine, ~dp0 was always current directory rather than "directory >> containing batch file" >>... >> +echo End test for bug 21382 > Also don't use bug numbers, add some meaningful message instead. The meaningful message is already there: >> +rem On old wine, ~dp0 was always current directory rather than "directory >> containing batch file" > The code must be understandable without reference to bugzilla. Agreed. 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? Apologies for the long email. irc would be better for this kind of disagreement, but I didn't see you online just now. - Dan