From 06edb19fed3bcd0b7fb889039eb531d6576fa1db Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Adam=20Chuda=C5=9B?= Date: Mon, 13 Nov 2023 15:45:03 +0100 Subject: [PATCH] Fix test related documentation issues --- docs/practices/testing/README.md | 21 ++++++++++----------- docs/practices/testing/python_tests.md | 8 ++++---- 2 files changed, 14 insertions(+), 15 deletions(-) diff --git a/docs/practices/testing/README.md b/docs/practices/testing/README.md index 265025fc3d1..20ce69817bc 100644 --- a/docs/practices/testing/README.md +++ b/docs/practices/testing/README.md @@ -36,19 +36,18 @@ It requires nextest harness which can be installed by running `cargo install car such tests is to enable all the features by passing `--all-features` to `cargo nextest run`, e.g: -`cargo nextest run --package near-client --test cross_shard_tx -tests::test_cross_shard_tx --all-features` +`cargo nextest run --package near-client -E 'test(=tests::cross_shard_tx::test_cross_shard_tx)' --all-features` 3. **Python tests:** We have an infrastructure to spin up nodes, both locally and remotely, in python, and interact with them using RPC. The infrastructure and the tests are located in the `pytest` folder. The infrastructure is relatively straightforward, see for example `block_production.py` - [here](https://github.com/nearprotocol/nearcore/blob/master/pytest/tests/sanity/block_production.py). + [here](https://github.com/near/nearcore/blob/master/pytest/tests/sanity/block_production.py). See the `Test infrastructure` section below for details. Expensive and python tests are not part of CI, and are run by a custom nightly runner. The results of the latest runs are available -[here](http://nightly.neartest.com/). Today, test runs launch approximately +[here](https://nayduck.near.org/#/). Today, test runs launch approximately every 5-6 hours. For the latest results look at the **second** run, since the first one has some tests still scheduled to run. @@ -71,7 +70,7 @@ predefined timeout. For the most basic example of using this infrastructure see `produce_two_blocks` in -[`tests/process_blocks.rs`](https://github.com/nearprotocol/nearcore/blob/master/chain/client/tests/process_blocks.rs). +[`tests/process_blocks.rs`](https://github.com/near/nearcore/blob/master/chain/client/src/tests/process_blocks.rs). 1. The callback (`Box::new(move |msg, _ctx, _| { ...`) is what is executed whenever the client sends a message. The return value of the callback is sent @@ -84,13 +83,13 @@ in For an example of a test that launches multiple nodes, see `chunks_produced_and_distributed_common` in -[tests/chunks_management.rs](https://github.com/nearprotocol/nearcore/blob/master/chain/client/tests/chunks_management.rs). +[tests/chunks_management.rs](https://github.com/near/nearcore/blob/master/chain/client/src/tests/chunks_management.rs). The `setup_mock_all_validators` function is the key piece of infrastructure here. ## Runtime Tests for Runtime are listed in -[tests/test_cases_runtime.rs](https://github.com/near/nearcore/blob/master/tests/test_cases_runtime.rs). +[tests/test_cases_runtime.rs](https://github.com/near/nearcore/blob/master/integration-tests/src/tests/standard_cases/runtime.rs). To run a test, usually, a mock `RuntimeNode` is created via `create_runtime_node()`. In its constructor, the `Runtime` is created in the @@ -114,16 +113,16 @@ make sure to build new components sufficiently abstract so that they can be test without relying on other components. For example, see tests for doomslug -[here](https://github.com/nearprotocol/nearcore/blob/master/chain/chain/tests/doomslug.rs), +[here](https://github.com/near/nearcore/blob/master/chain/chain/src/tests/doomslug.rs), for network cache -[here](https://github.com/nearprotocol/nearcore/blob/master/chain/network/tests/cache_edges.rs), +[here](https://github.com/near/nearcore/blob/master/chain/network/src/routing/edge_cache/tests.rs), or for promises in runtime -[here](https://github.com/nearprotocol/nearcore/blob/master/runtime/near-vm-logic/tests/test_promises.rs). +[here](https://github.com/near/nearcore/blob/master/runtime/near-vm-runner/src/logic/tests/promises.rs). ## Python tests See -[this page](https://github.com/nearprotocol/nearcore/wiki/Writing-integration-tests-for-nearcore) +[this page](python_tests.md) for detailed coverage of how to write a python test. We have a python library that allows one to create and run python tests. diff --git a/docs/practices/testing/python_tests.md b/docs/practices/testing/python_tests.md index 95ebb9d8b77..d1922eba288 100644 --- a/docs/practices/testing/python_tests.md +++ b/docs/practices/testing/python_tests.md @@ -63,7 +63,7 @@ want to run tests against a release build, you can create a file with the following config: ```json -{"local": True, "near_root": "../target/release/"} +{"local": true, "near_root": "../target/release/"} ``` and run the test with the following command: @@ -116,7 +116,7 @@ Note that `start_cluster` spins up all the nodes right away. Some tests (e.g. tests that test syncing) might want to configure the nodes but delay their start. In such a case you will initialize the cluster by calling `init_cluster` and will run the nodes manually, for example, see -[`state_sync.py`](https://github.com/nearprotocol/nearcore/blob/master/pytest/tests/sanity/state_sync.py) +[`state_sync.py`](https://github.com/near/nearcore/blob/master/pytest/tests/sanity/state_sync.py) ## Connecting to a mocknet @@ -234,7 +234,7 @@ if want_async: ``` See -[rpc_tx_forwarding.py](https://github.com/nearprotocol/nearcore/blob/master/pytest/tests/sanity/rpc_tx_forwarding.py) +[rpc_tx_forwarding.py](https://github.com/near/nearcore/blob/master/pytest/tests/sanity/rpc_tx_forwarding.py) for an example of signing and submitting a transaction. ## Adversarial behavior @@ -269,6 +269,6 @@ See the tests that match `tests/sanity/proxy_*.py` for examples. We always welcome new tests, especially python tests that use the above infrastructure. We have a list of test requests -[here](https://github.com/nearprotocol/nearcore/issues?q=is%3Aissue+is%3Aopen+label%3A%22good+first+test%22+), +[here](https://github.com/nearprotocol/nearcore/issues?q=is%3Aissue+is%3Aopen+label%3A%22A-testing%22), but also welcome any other tests that test aspects of the network we haven't thought about.