Need to make match of preceding priority optional.
Also tighten patterns for priority and done marker by anchoring them to the front, as the leading task number has already been substituted away.
When the command-under-test fails with a non-zero exit code, neither the different exit code nor any output differences are printed. Also, there's a lot of duplication between test_expect_output and test_expect_code_and_output. So, let's fix both by delegating the first to the latter.
Currently, the only way to get usage help for a custom action is to use "todo.sh help" and scroll / search for the action name. (Or try to call the action without / with invalid parameters to hopefully get a one-line syntax summary.)
This extends the help command to print the usage of optionally passed custom action names.
This applies e24777fa2c to todo.cfg, too, and adds a verification to the existing test.
Note: Because todo.cfg is preprocessed by test-lib, we use the original config from the working copy, not the copy inside the test fixture.
An empty line is used to delimit test commands in test_todo_session. (This wasn't properly reflected in the usage comment, fixed that, too.) This prevents us from testing commands that include empty lines. (Currently, there is no such output in todo.sh, but custom add-ons may have this.)
Instead of forcing the test to filter out the empty lines, extend the syntax to allow empty lines in the expected output by escaping them with a single backslash. (When redirecting via <<EOF, the backslash itself must be escaped = doubled; better use <<'EOF'.)
Currently, todo.sh produces no indented output, so this hasn't affected tests so far. I found this while testing one of my custom actions with the test-lib.
By unsetting IFS, the read command won't strip off leading and trailing whitespace while parsing the test session definition.
The todo_completion had the problem that it didn't consider the todo.cfg itself for the location of TODO_ACTIONS_DIR, it just tried the default location or a globally exported config value. With the injection of custom configuration now in place, we can actually delegate the listing to todo.sh itself.
The added built-in "listaddons" command is used for that; it may also be helpful for troubleshooting or to find out about available add-ons. (But the help / shorthelp commands offer more information.)
Additionally, completion is now more precise; only executable actions and no subdirs are listed now; this is also covered by the enhanced test.
The last bonus: The custom add-on actions are now only determined when there's actually completion of commands.
This was previously not supported; todo_completion always used plain todo.sh from the PATH. Now it's possible to override the used executable (and configuration used through _todo_sh, set from a completion function wrapper.
Cp. http://tech.groups.yahoo.com/group/todotxt/message/4003
This extension of test_todo_completion additionally takes the completion function to use, so that customized completions for todo.sh aliases can be tested.
The completion may unexpectedly abort somewhere.
Additionally, reformat the failure messages (don't prepend a "*", this should be reserved to mark the individual test runs) and use "compreply" instead of "output", so that it's already clear from the diff output that the completion is being tested.
There should be a trailing newline when there are completions (to avoid diff complaining about "no trailing newline", but not when there are no completions at all.
Before adding any more features to todo_completion, I feel like I need test coverage, so this is a first stab at testing the completion results, via a new test function test_todo_completion.
Some basic tests showcase the capabilities.
Note: test-lib.sh now uses arrays, therefore all tests must use /bin/bash, not /bin/sh to avoid errors when sourcing test-lib. For consistency with todo.sh, we should have used Bash everywhere, anyway. Also note that t2000-multiline.sh needs some more quoting to avoid "Bash: ambiguous redirect" errors.
So far, the listpri action only supports a single priority. Allowing priority ranges (e.g. todo.sh listpri A-C @work) is a simple but useful enhancement.
Note: The syntax extension only clashes with the [TERM] filtering in a few corner cases, and this can be worked around (e.g. "todo.sh listpri A-Z A-Z" lists all prioritized tasks containing the text A-Z).
The test aggregate results are easy to miss when running the entire test suite via "make test", as the status of the last test case is highlighted, but the aggregate results appear in an unformatted, uncolored block of text.
Copy the say_color() function from test-lib.sh. (Sorry for the duplication, I found no simple way to import or share just this piece of functionality without adding much complexity.)
Successes, errors and broken summaries will now be highlighted in the appropriate colors (unless --no-color is given or output is not to a terminal), but only if the number is more than zero.
Now that differences in the output (and exit code) are already printed by default, we can make the verbose mode actually "verbose" by including all todo.sh output generated during the test run. This may help in reviewing the tests and for troubleshooting.
By moving the redirection to the output file to test_run_(), all testing-related embellishments have been removed from the command under test itself, resulting in much cleaner test messages.
Additionally, also capture stderr in output. todo.sh itself currently prints everything to stdout (but the die() output probably belongs to stderr), so as of now, that has no consequences, but seems to be more consistent and future-proof.
Remove the check for the todo.sh exit code (scripted via "=== N") from the command under test into a separate assertion test_expect_code_and_output. This allows for reporting of expected vs. actual exit code (also in the default non-verbose mode), and unexpected output from the same test is now reported, too.
Differences in the expected and actual todo.sh output are critical to analyzing the error, so they should always be printed, not just when the -verbose argument is given.
This refactoring moves the test_cmp call from the command under test (as seen from test-lib's perspective) into a new assertion test_expect_output, derived from test_expect_success.
The sed command of BSD / OS X doesn't like { command } blocks in a single expression. So move the (dynamic) deduplicate sed command(s) to the end, and use a label to access them. This also makes the entire sed script somewhat easier to understand.
