mirror of
https://github.com/ipfs/kubo.git
synced 2026-02-26 12:57:44 +08:00
f630222580
This commit introduces non-recursive Makefile infrastructure that replaces current Makefile infrastructure. It also generally cleanups the Makefiles, separates them into nicer sub-modules and centralizes common operations into single definitions. It allows to depend on any target that is defined in the makefile, this means that for example `gx install` is called once when `make build test_expensive_sharness` is called instead of 4 or 5 times. It also makes the dependencies much cleaner and allows for reuse of modules. For example sharness coverage collection (WIP) uses sharness target with amended PATH, previously it might have been possible but not without wiring in the coverage collection into sharness make runner code. Yes, it is more complex but not much more. There are few rules that have to be followed and few complexities added but IMHO it is worth it. How to NR-make: 1. If make is to generate some file via a target, it MUST be defined in Rules.mk file in the directory of the target. 2. `Rules.mk` file MUST have `include mk/header.mk` statement as the first line and `include mk/footer.mk` statement as the last line (apart from project root `Rules.mk`). 3. It then MUST be included by the closest `Rules.mk` file up the directory tree. 4. Inside a `Rules.mk` special variable accessed as `$(d)` is defined. Its value is current directory, use it so if the `Rules.mk` file is moved in the tree it still works without a problem. Caution: this variable is not available in the recipe part and MUST NOT be used. Use name of the target or prerequisite to extract it if you need it. 5. Make has only one global scope, this means that name conflicts are a thing. Names SHOULD follow `VAR_NAME_$(d)` convention. There are exceptions from this rule in form of well defined global variables. Examples: General lists `TGT_BIN`, `CLEAN`; General targets: `TEST`, `COVERAGE`; General variables: `GOFLAGS`, `DEPS_GO`. 3. Any rules, definitions or variables that fit some family SHOULD be defined in `mk/$family.mk` file and included from project root `Rules.mk` License: MIT Signed-off-by: Jakub Sztandera <kubuxu@protonmail.ch>
125 lines
3.0 KiB
Markdown
125 lines
3.0 KiB
Markdown
# ipfs whole tests using the [sharness framework](https://github.com/mlafeldt/sharness/)
|
|
|
|
## Running all the tests
|
|
|
|
Just use `make` in this directory to run all the tests.
|
|
Run with `TEST_VERBOSE=1` to get helpful verbose output.
|
|
|
|
```
|
|
TEST_VERBOSE=1 make
|
|
```
|
|
|
|
The usual ipfs env flags also apply:
|
|
|
|
```sh
|
|
# the output will make your eyes bleed
|
|
IPFS_LOGGING=debug TEST_VERBOSE=1 make
|
|
```
|
|
|
|
## Running just one test
|
|
|
|
You can run only one test script by launching it like a regular shell
|
|
script:
|
|
|
|
```
|
|
$ ./t0010-basic-commands.sh
|
|
```
|
|
|
|
## Debugging one test
|
|
|
|
You can use the `-v` option to make it verbose and the `-i` option to
|
|
make it stop as soon as one test fails.
|
|
For example:
|
|
|
|
```
|
|
$ ./t0010-basic-commands.sh -v -i
|
|
```
|
|
|
|
## Sharness
|
|
|
|
When running sharness tests from main Makefile or when `test_sharness_deps`
|
|
target is run dependencies for sharness
|
|
will be downloaded from its github repo and installed in a "lib/sharness"
|
|
directory.
|
|
|
|
Please do not change anything in the "lib/sharness" directory.
|
|
|
|
If you really need some changes in sharness, please fork it from
|
|
[its cannonical repo](https://github.com/mlafeldt/sharness/) and
|
|
send pull requests there.
|
|
|
|
## Writing Tests
|
|
|
|
Please have a look at existing tests and try to follow their example.
|
|
|
|
When possible and not too inefficient, that means most of the time,
|
|
an ipfs command should not be on the left side of a pipe, because if
|
|
the ipfs command fails (exit non zero), the pipe will mask this failure.
|
|
For example after `false | true`, `echo $?` prints 0 (despite `false`
|
|
failing).
|
|
|
|
It should be possible to put most of the code inside `test_expect_success`,
|
|
or sometimes `test_expect_failure`, blocks, and to chain all the commands
|
|
inside those blocks with `&&`, or `||` for diagnostic commands.
|
|
|
|
### Diagnostics
|
|
|
|
Make your test case output helpful for when running sharness verbosely.
|
|
This means cating certain files, or running diagnostic commands.
|
|
For example:
|
|
|
|
```
|
|
test_expect_success ".ipfs/ has been created" '
|
|
test -d ".ipfs" &&
|
|
test -f ".ipfs/config" &&
|
|
test -d ".ipfs/datastore" &&
|
|
test -d ".ipfs/blocks" ||
|
|
test_fsh ls -al .ipfs
|
|
'
|
|
```
|
|
|
|
The `|| ...` is a diagnostic run when the preceding command fails.
|
|
test_fsh is a shell function that echoes the args, runs the cmd,
|
|
and then also fails, making sure the test case fails. (wouldnt want
|
|
the diagnostic accidentally returning true and making it _seem_ like
|
|
the test case succeeded!).
|
|
|
|
|
|
### Testing commands on daemon or mounted
|
|
|
|
Use the provided functions in `lib/test-lib.sh` to run the daemon or mount:
|
|
|
|
To init, run daemon, and mount in one go:
|
|
|
|
```sh
|
|
test_launch_ipfs_daemon_and_mount
|
|
|
|
test_expect_success "'ipfs add --help' succeeds" '
|
|
ipfs add --help >actual
|
|
'
|
|
|
|
# other tests here...
|
|
|
|
# dont forget to kill the daemon!!
|
|
test_kill_ipfs_daemon
|
|
```
|
|
|
|
To init, run daemon, and then mount separately:
|
|
|
|
```sh
|
|
test_init_ipfs
|
|
|
|
# tests inited but not running here
|
|
|
|
test_launch_ipfs_daemon
|
|
|
|
# tests running but not mounted here
|
|
|
|
test_mount_ipfs
|
|
|
|
# tests mounted here
|
|
|
|
# dont forget to kill the daemon!!
|
|
test_kill_ipfs_daemon
|
|
```
|