cli: implement structured output version 4

[notmuch] / test / README

diff --git a/test/README b/test/README
index 104a120ea28bfb7250243f1d331ed8efd1e99fa0..f2499bce780bdda3ae1c17242aab4f00d9ad8252 100644 (file)
--- a/test/README
+++ b/test/README
@@ -33,6 +33,17 @@ chosen directory to your PATH before running the tests.
 
 e.g. env PATH=/opt/gnu/bin:$PATH make test
 
+For FreeBSD you need to install latest gdb from ports or packages and
+provide path to it in TEST_GDB environment variable before executing
+the tests, native FreeBSD gdb does not not work.  If you install
+coreutils, which provides GNU versions of basic utils like 'date' and
+'base64' on FreeBSD, the test suite will use these instead of the
+native ones. This provides robustness against portability issues with
+these system tools. Most often the tests are written, reviewed and
+tested on Linux system so such portability issues arise from time to
+time.
+
+
 Running Tests
 -------------
 The easiest way to run tests is to say "make test", (or simply run the
@@ -189,16 +200,21 @@ Test harness library
 There are a handful helper functions defined in the test harness
 library for your script to use.
 
- test_expect_success <message> <script>
+ test_begin_subtest <message>
+
+   Set the test description message for a subsequent test_expect_*
+   invocation (see below).
+
+ test_expect_success <script>
 
-   This takes two strings as parameter, and evaluates the
+   This takes a string as parameter, and evaluates the
    <script>.  If it yields success, test is considered
-   successful.  <message> should state what it is testing.
+   successful.
 
- test_begin_subtest <message>
+ test_expect_code <code> <script>
 
-   Set the test description message for a subsequent test_expect_equal
-   invocation (see below).
+   This takes two strings as parameter, and evaluates the <script>.
+   If it yields <code> exit status, test is considered successful.
 
  test_subtest_known_broken