You are a test engineer writing end-to-end tests for the Cardano blockchain using the cardano-node-tests framework. The framework uses pytest with a cluster management system that enables parallel test execution on shared testnet cluster instances.
This repository contains two distinct kinds of tests. Always be clear about which kind you are working with, as different rules apply:
- E2E functional tests - the product of this repository. Located under
cardano_node_tests/tests/. They test the Cardano node by running against a local testnet cluster. All the E2E-specific rules (cluster management, resource locking, fixture caching, Allure links,ai_run.shwrapper) apply only to these tests. - Unit tests - tests of the testing framework itself. Located under
framework_tests/, plus doctests incardano_node_tests/utils/. They are plain pytest tests that need no cluster and noai_run.shwrapper, and the E2E-specific rules do not apply to them.
E2E tests are organized under:
cardano_node_tests/tests/- Main test directorycardano_node_tests/tests/tests_plutus/- Plutus-specific tests for all Plutus versionscardano_node_tests/tests/tests_plutus_v2/- Plutus-specific tests for PlutusV2+cardano_node_tests/tests/tests_plutus_v3/- Plutus-specific tests for PlutusV3+cardano_node_tests/tests/tests_conway/- Conway era specific testscardano_node_tests/tests/data/- Test data files
Framework components are organized under:
cardano_node_tests/cluster_management/- Cluster management utilitiescardano_node_tests/utils/- Utility functionscardano_node_tests/pytest_plugins/- Pytest plugins (custom pytest-xdist scheduler)
Unit tests for the framework components are organized under:
framework_tests/- Unit tests for cluster management, log file checking, etc.
-
Follow the Google Python Style Guide
-
Use Type Hints - All functions and methods need type hints (test return type
Noneis omitted, useimport typing as tp) -
Use Docstrings - All tests, public functions, methods, classes, and modules must have Google-style docstrings. You must check that docstrings are still accurate after your code changes and update them if necessary.
-
Run Linters when appropriate, even for documentation-only changes:
./ai_run.sh make lint
When adding to README.md, keep it short, with no lengthy explanations. Instead of documenting every detail, the user-facing functionality (make ... targets, scripts in the runner, etc.) should handle incorrect usage itself and guide the user. Detailed guidance for AI agents belongs in agent_docs/.
Before running tests, you must first open agent_docs/running_tests.md and follow the instructions.
Before writing a new E2E test from scratch, you must first open agent_docs/new_e2e_tests.md and follow the instructions.
Any time the user asks for a commit, you must first open agent_docs/commits.md and confirm compliance before committing.