@cryptotaxi247 / kubo
Code Commits Issues Pulls Sessions CI/CD
master
master
md 131 lines 3.16 KB
Rendered Raw
1 # ipfs whole tests using the [sharness framework](https://github.com/pl-strflt/sharness/tree/feat/junit)
2
3 ## Running all the tests
4
5 Just use `make` in this directory to run all the tests.
6 Run with `TEST_VERBOSE=1` to get helpful verbose output.
7
8 ```
9 TEST_VERBOSE=1 make
10 ```
11
12 The usual ipfs env flags also apply:
13
14 ```sh
15 # the output will make your eyes bleed
16 GOLOG_LOG_LEVEL=debug TEST_VERBOSE=1 make
17 ```
18
19 To make the tests abort as soon as an error occurs, use the TEST_IMMEDIATE env variable:
20
21 ```sh
22 # this will abort as soon the first error occurs
23 TEST_IMMEDIATE=1 make
24 ```
25
26 ## Running just one test
27
28 You can run only one test script by launching it like a regular shell
29 script:
30
31 ```
32 $ ./t0010-basic-commands.sh
33 ```
34
35 ## Debugging one test
36
37 You can use the `-v` option to make it verbose and the `-i` option to
38 make it stop as soon as one test fails.
39 For example:
40
41 ```
42 $ ./t0010-basic-commands.sh -v -i
43 ```
44
45 ## Sharness
46
47 When running sharness tests from main Makefile or when `test_sharness_deps`
48 target is run dependencies for sharness
49 will be downloaded from its GitHub repo and installed in a "lib/sharness"
50 directory.
51
52 Please do not change anything in the "lib/sharness" directory.
53
54 If you really need some changes in sharness, please fork it from
55 [its canonical repo](https://github.com/mlafeldt/sharness/) and
56 send pull requests there.
57
58 ## Writing Tests
59
60 Please have a look at existing tests and try to follow their example.
61
62 When possible and not too inefficient, that means most of the time,
63 an ipfs command should not be on the left side of a pipe, because if
64 the ipfs command fails (exit non zero), the pipe will mask this failure.
65 For example after `false | true`, `echo $?` prints 0 (despite `false`
66 failing).
67
68 It should be possible to put most of the code inside `test_expect_success`,
69 or sometimes `test_expect_failure`, blocks, and to chain all the commands
70 inside those blocks with `&&`, or `||` for diagnostic commands.
71
72 ### Diagnostics
73
74 Make your test case output helpful for when running sharness verbosely.
75 This means cating certain files, or running diagnostic commands.
76 For example:
77
78 ```
79 test_expect_success ".ipfs/ has been created" '
80 test -d ".ipfs" &&
81 test -f ".ipfs/config" &&
82 test -d ".ipfs/datastore" &&
83 test -d ".ipfs/blocks" ||
84 test_fsh ls -al .ipfs
85 '
86 ```
87
88 The `|| ...` is a diagnostic run when the preceding command fails.
89 test_fsh is a shell function that echoes the args, runs the cmd,
90 and then also fails, making sure the test case fails. (wouldn't want
91 the diagnostic accidentally returning true and making it _seem_ like
92 the test case succeeded!).
93
94
95 ### Testing commands on daemon or mounted
96
97 Use the provided functions in `lib/test-lib.sh` to run the daemon or mount:
98
99 To init, run daemon, and mount in one go:
100
101 ```sh
102 test_launch_ipfs_daemon_and_mount
103
104 test_expect_success "'ipfs add --help' succeeds" '
105 ipfs add --help >actual
106 '
107
108 # other tests here...
109
110 # don't forget to kill the daemon!!
111 test_kill_ipfs_daemon
112 ```
113
114 To init, run daemon, and then mount separately:
115
116 ```sh
117 test_init_ipfs
118
119 # tests inited but not running here
120
121 test_launch_ipfs_daemon
122
123 # tests running but not mounted here
124
125 test_mount_ipfs
126
127 # tests mounted here
128
129 # don't forget to kill the daemon!!
130 test_kill_ipfs_daemon
131 ```