vis

a vi-like editor based on Plan 9's structural regular expressions
README.md

(1987B)
      1 Testing Infrastructure for Vis
      2 ------------------------------
      3 
      4 This repository contains testing infrastructure for the
      5 [vis editor](https://github.com/martanne/vis). It is expected
      6 to be cloned into a sub directory of the `vis` source tree.
      7 
      8 There exist 5 different kinds of tests:
      9 
     10  * `core` are C unit tests for core data structures used by vis
     11  * `fuzz` infrastructure for automated fuzzing
     12  * `vim` tests vim compatibility
     13  * `sam` tests sam compatibility of the command language
     14  * `vis` contains tests for vis specific behavior/features
     15  * `lua` contains tests for the vis specific lua api
     16 
     17 Run `make` to execute all test suites.
     18 
     19 Writing good tests
     20 ------------------
     21 
     22 Each sub directory contains a README with further information
     23 about the specific test method.
     24 
     25 Coming up with good and exhaustive tests is often non-trivial,
     26 below are some recommendations:
     27 
     28  * Make sure you understand what the expected behavior you
     29    want to test is. Think about possible error conditions.
     30 
     31  * Test something specific, but keep the overall context in mind.
     32 
     33    For vi(m) frontend related tests consider behavior when given
     34    a count or when the command is repeated (using `.`).
     35 
     36    For example the motions `f`, `F`, `t`, `T` also influence `;` and `,`.
     37    Similar, `*` and `#` affect `n` and `N`.
     38 
     39  * Test special cases, these often reveal interesting behavior.
     40 
     41    Continuing the motion example these might be: empty lines, single
     42    letter words, no matches, consecutive matches, over-specified counts,
     43    etc.
     44 
     45  * Test systematically and strive for high test coverage.
     46 
     47    It is preferable to have a small set of tests which cover a specific
     48    functionality exhaustively, rather than lots of half-baked tests which
     49    only test the basics.
     50 
     51    A good first indication of the completeness of your tests is the
     52    [achieved code coverage](https://codecov.io/gh/martanne/vis). Ideally
     53    a test should primarily exercise a small set of functions which should
     54    achieve high path coverage.