Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/RGB-WG/rgb-tests
RGB tests
https://github.com/RGB-WG/rgb-tests
Last synced: 3 months ago
JSON representation
RGB tests
- Host: GitHub
- URL: https://github.com/RGB-WG/rgb-tests
- Owner: RGB-WG
- License: apache-2.0
- Created: 2024-04-23T14:07:35.000Z (10 months ago)
- Default Branch: master
- Last Pushed: 2024-09-18T08:37:15.000Z (5 months ago)
- Last Synced: 2024-09-18T17:43:43.897Z (5 months ago)
- Language: Rust
- Homepage:
- Size: 106 KB
- Stars: 2
- Watchers: 3
- Forks: 8
- Open Issues: 6
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
- awesome-rgb-protocol - RGB Integration Tests
README
# RGB tests
This repository contains tests for RGB.
## Requirements
- Linux OS
- Docker with its `compose` plugin
- Rust
## Run
Clone the project, including submodules:
```sh
git clone https://github.com/RGB-WG/rgb-tests --recurse-submodules
```
Note: after checking out to another commit, remember to run:
```sh
git submodule update
```
### Integration tests
To run the integration tests, from the project root, execute:
```sh
cargo test --test issuance --test transfers
```
:warning: **Warning:** if your machine has a lot of CPU cores, it could
happen that calls to indexers fail because of too many parallel requests. To
limit the test threads and avoid this issue set the `--test-threads` option
(e.g. `cargo test --test issuance --test transfers -- --test-threads=8`).
### Validation tests
To run consignment validation tests, from the project root, execute:
```sh
cargo test --test validation
```
### Stress tests
To run a single stress test, set the `LOOPS` variable to the requested number
of loops and then, from the project root, for example execute:
```sh
LOOPS=20 cargo test --test stress back_and_forth::case_1 -- --ignored
```
This will produce a CSV report file that can be opened in a spreadsheet program
manually or by running:
```sh
open test-data/stress/.csv
```
Stress tests have been parametrized the same way some integration tests are.
To select which test case you want to run, find the case attribute you want to
use (e.g. `#[case(TT::Witness, DT::Wpkh, DT::Tr)]`) and if, as an example, it's
the 4th one, run `::case_4`. Note that case numbers are zero-padded
so if for example there are 20 test cases, case 4 would be called `case_04`.
### Test services
Test services will be automatically (re)started by the test command and will
run in docker containers.
If you don't have the docker images they will be automatically pulled. Note
that in this case the first test execution will be slower.
Also note that there's no automatic shutdown of test services, you'll need to
manually remove the docker containers with:
```sh
docker compose -f tests/docker-compose.yml --profile='*' down -v --remove-orphans
```
The indexer used by the tests is configurable, currently esplora and electrum
are supported. You can change the indexer type by setting the `INDEXER`
environment variable, for example:
```sh
INDEXER=esplora cargo test # default
INDEXER=electrum cargo test
```
If you are developing new tests and want a faster execution, you can set
`SKIP_INIT=1` to avoid restarting the test services. Please note that you
cannot switch to another indexer when using this option, you'll have to use the
same indexer type from the previous test execution.
### Coverage
To run the tests and generate a code coverage report run:
```sh
./tests/coverage.sh
```
This will generate a report in `target/llvm-cov/html/index.html` that you can
visualize on a browser (e.g. `firefox target/llvm-cov/html/index.html`).
Coverage will be measured for all patched crates.
The GitHub organizations of submodule repositories are:
- https://github.com/RGB-WG
- https://github.com/LNP-BP
- https://github.com/BP-WG
- https://github.com/aluvm
- https://github.com/strict-types
- https://github.com/rust-amplify
- https://github.com/UBIDECO
## Contribute
### Submodule revision change helper
A helper to change the revision for all submodules is available in the form of
the `sub-rev-change.sh` script.
As an example, it can be used to update all submodules to the `master` branch
with:
```sh
./sub-rev-change.sh --branch master
```
See the help for more details on its usage:
```sh
./sub-rev-change.sh --help
```