diff options
| -rw-r--r-- | build2/test/testscript | 38 |
1 files changed, 30 insertions, 8 deletions
diff --git a/build2/test/testscript b/build2/test/testscript index c2e2365..d7a70f6 100644 --- a/build2/test/testscript +++ b/build2/test/testscript @@ -3,10 +3,10 @@ Requirements ============ -* Multiple testscript files (to group related test) - * Run multiple tests +* Multiple testscript files (to group related test) + * Specify exit status (optional, expect 0 by default). * Run pre/post test actions (setups/teardowns, e.g., database schema creation). @@ -19,18 +19,18 @@ Requirements * Test description -* Create (and automatically clean up) input files +* Create (and automatically clean up) input/output files ? Variable expansion, looked up on target in buildfile * Ability to pass arguments from build files (how for multiple scripts?) - Could use $0, $1, $* if have variable expansion. + Could use $0, $1, $*. Questions ========= -* What is the testcript attached at the buildfile level? An executable? What - if the test is not for executable. I guess we always have the directory +* What if the testcript attached at the buildfile level? An executable? What + if the test is not for an executable. I guess we always have the directory target. We could reuse the test variable to specify (list of) scripts: @@ -38,7 +38,8 @@ Questions exe{hello}: test = test1 test2 * Do we want a notion of multi-command test (e.g., with pre/post commands)? - Maybe {}? Will need it not to clean up output files too early. + Maybe {}? Will need it not to clean up output files too early. Also var + scope. Notes ===== @@ -74,7 +75,28 @@ EOO 13 characters written EOE -~ Built in cat command with auto-cleanup? To create files for tests, etc. +~ Built-in cat command with auto-cleanup? To create files for tests, etc. + +~ Built-in sed(-like) utility? Note that GCC 4.8 has broken <regex> support, + only usable from 4.9. Could be a problem. + +~ We should probably allow assignment of variables and since we will also + lookup those defined in the buildfile, makes sense to use the same semantics + (and perhaps even the parser, like we do for command line). Also value + types. + + So in a sense for each test we will have an "inner" variable scope where + we lookup first. + +~ Could support assigning output of a program to a variable: + + foo = `sed ...` + + The semantics should probably be "as if you had the output literally", + without any of the extra shell splitting nonsense, just the standard + buildfile logic. + + Probably also support piping. ~ Output file redirects should be relative to out_base. Input? Could actually track created out files and use that if exists, and src otherwise. What if |