test: add some general testing tips

1 files changed, 38 insertions, 0 deletions

diff --git a/README.md b/README.md
index 37a25d3..09255ec 100644
--- a/README.md
+++ b/README.md
@@ -8,9 +8,47 @@ to be cloned into a sub directory of the `vis` source tree.
 There exist 5 different kinds of tests:
 
  * `core` are C unit tests for core data structures used by vis
+ * `fuzz` infrastructure for automated fuzzing
  * `vim` tests vim compatibility
  * `sam` tests sam compatibility of the command language
  * `vis` contains tests for vis specific behavior/features
  * `lua` contains tests for the vis specific lua api
 
 Run `make` to execute all test suites.
+
+Writing good tests
+------------------
+
+Each sub directory contains a README with further information
+about the specific test method.
+
+Coming up with good and exhaustive tests is often non-trivial,
+below are some recommendations:
+
+ * Make sure you understand what the expected behavior you
+   want to test is. Think about possible error conditions.
+
+ * Test something specific, but keep the overall context in mind.
+
+   For vi(m) frontend related tests consider behavior when given
+   a count or when the command is repeated (using `.`).
+
+   For example the motions `f`, `F`, `t`, `T` also influence `;` and `,`.
+   Similar, `*` and `#` affect `n` and `N`.
+
+ * Test special cases, these often reveal interesting behavior.
+
+   Continuing the motion example these might be: empty lines, single
+   letter words, no matches, consecutive matches, over-specified counts,
+   etc.
+
+ * Test systematically and strive for high test coverage.
+
+   It is preferable to have a small set of tests which cover a specific
+   functionality exhaustively, rather than lots of half-baked tests which
+   only test the basics.
+
+   A good first indication of the completeness of your tests is the
+   [achieved code coverage](https://codecov.io/gh/martanne/vis). Ideally
+   a test should primarily exercise a small set of functions which should
+   achieve high path coverage.