File: README.md

package info (click to toggle)
vis 0.8-1
  • links: PTS, VCS
  • area: main
  • in suites: bookworm
  • size: 12,388 kB
  • sloc: ansic: 22,372; sh: 950; makefile: 356; python: 47
file content (54 lines) | stat: -rw-r--r-- 1,987 bytes parent folder | download | duplicates (4)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
Testing Infrastructure for Vis
------------------------------

This repository contains testing infrastructure for the
[vis editor](https://github.com/martanne/vis). It is expected
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.