home / skills / redisearch / redisearch / run-python-tests

run-python-tests skill

/.skills/run-python-tests

This skill runs end-to-end Python tests after changes to quickly verify correctness and regression safety.

npx playbooks add skill redisearch/redisearch --skill run-python-tests

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
3.5 KB
---
name: run-python-tests
description: Run end-to-end Python tests after making changes to verify correctness
---

# Run Python Tests Skill

Run end-to-end Python tests after making changes to verify correctness.

## Arguments
- No arguments: Run all Python tests
- `<filename>`: Run all Python tests in the specified file
- `<filename>:<test_name>`: Run a specific Python test in the specified file
- `<filename 1> <filename 2>`: Run all Python tests in the specified files

Arguments provided: `$ARGUMENTS`

## Instructions

### Test Timeout

Some tests take longer to run than others. The `TEST_TIMEOUT` parameter controls how long each test is allowed to run before being terminated.

- **Quick verification (preferred)**: Pass `TEST_TIMEOUT=20` to get fast feedback. Tests that exceed this timeout will be terminated.
- **Full test run**: Omit `TEST_TIMEOUT` to let tests run with the default timeout (300 seconds).

**Always start with a quick verification, using `TEST_TIMEOUT=20`**. Faster feedback loops lead to faster iteration.

If there are timeouts during a quick verification run, check if the timed-out tests are relevant to the current task:
- If you can determine relevance autonomously (e.g., the test name clearly relates to the code you changed), re-run those specific tests without a timeout.
- If you cannot determine relevance, ask the user whether the timed-out tests should be re-run without a timeout.

### All Tests

```bash
./build.sh RUN_PYTEST ENABLE_ASSERT=1 TEST_TIMEOUT=20
```

### All Tests From A Specific File

```bash
source .venv/bin/activate && ./build.sh RUN_PYTEST ENABLE_ASSERT=1 TEST_TIMEOUT=20 TEST="<filename without extension>"
```

For example:

```bash
source .venv/bin/activate && ./build.sh RUN_PYTEST ENABLE_ASSERT=1 TEST_TIMEOUT=20 TEST="test_crash"
```

for running tests from `tests/pytests/test_crash.py`.

### All Tests From Multiple Files

```bash
source .venv/bin/activate && ./build.sh RUN_PYTEST ENABLE_ASSERT=1 TEST_TIMEOUT=20 TEST="<filename 1> <filename 2>"
```

For example:

```bash
source .venv/bin/activate && ./build.sh RUN_PYTEST ENABLE_ASSERT=1 TEST_TIMEOUT=20 TEST="test_crash test_gc"
```

for running tests from `tests/pytests/test_crash.py` and `tests/pytests/test_gc.py`.

### Specific Test From A Specific File

```bash
source .venv/bin/activate && ./build.sh RUN_PYTEST ENABLE_ASSERT=1 TEST_TIMEOUT=20 TEST="<filename without extension>:<test_name>"
```

For example:

```bash
source .venv/bin/activate && ./build.sh RUN_PYTEST ENABLE_ASSERT=1 TEST_TIMEOUT=20 TEST="test_crash:test_query_thread_crash"
```

for running the `test_query_thread_crash` test from `tests/pytests/test_crash.py`.

## Interpreting The Test Output

For each failed test, you'll see an error message with details about the failure, as seen _from the Python test runner_.
Each failed test will also have an associated log file, located under `tests/pytests/logs`. The name of the log file
changes with every test run, but it's included in the output of the test runner.

## Report

After running the tests, put together a report:

- Number of tests passed
- Number of tests failed
- Number of tests skipped
- For each failing test:
  - The error message reported in the test output, on the Python side
  - The stack trace from the server logs for the Redis server:
    - If the panic is in Rust code, include the Rust panic message and the Rust backtrace (from the `# search_rust_backtrace` section)
    - If the crash is in C code, include just the C backtrace.
  - Path to the log file, relative to the root of the repository

Overview

This skill runs end-to-end Python tests after code changes to verify correctness against the query and indexing engine for Redis. It supports running all tests, tests in specific files, or individual test functions and produces a concise report with failures, logs, and backtraces. Use it to get quick verification or perform full test runs when needed.

How this skill works

The skill invokes the project build and pytest harness via the provided build script, with an optional TEST or TEST_TIMEOUT environment variable to limit scope or runtime. It activates the virtual environment, runs tests with ENABLE_ASSERT=1, captures test output and server logs under tests/pytests/logs, and collects Python error messages plus server backtraces for any failures. After execution it produces a summary report listing passed/failed/skipped counts and details for each failure.

When to use it

  • After making code changes that may affect query, index, or search behavior.
  • When verifying a bug fix to ensure regression tests pass.
  • Before submitting a patch or pull request to catch runtime crashes.
  • When CI is flaky and a local, focused rerun is needed.
  • To reproduce and collect artifacts for a failing test reported elsewhere.

Best practices

  • Always start with a quick verification: set TEST_TIMEOUT=20 for fast feedback.
  • If a quick run times out, re-run only the relevant tests without TEST_TIMEOUT.
  • Scope runs using TEST to limit files or test names and speed iteration.
  • Include ENABLE_ASSERT=1 to catch assertion failures during tests.
  • Collect and attach the matching server log file from tests/pytests/logs when reporting failures.

Example use cases

  • Run all tests quickly: ./build.sh RUN_PYTEST ENABLE_ASSERT=1 TEST_TIMEOUT=20
  • Run tests in one file: source .venv/bin/activate && ./build.sh RUN_PYTEST ENABLE_ASSERT=1 TEST_TIMEOUT=20 TEST="test_crash"
  • Run two files: source .venv/bin/activate && ./build.sh RUN_PYTEST ENABLE_ASSERT=1 TEST_TIMEOUT=20 TEST="test_crash test_gc"
  • Run a single test: source .venv/bin/activate && ./build.sh RUN_PYTEST ENABLE_ASSERT=1 TEST_TIMEOUT=20 TEST="test_crash:test_query_thread_crash"
  • Perform full run without timeout by omitting TEST_TIMEOUT for thorough validation.

FAQ

What does TEST_TIMEOUT do?

TEST_TIMEOUT sets a per-test time limit in seconds; use 20 for quick checks or omit it for the default 300s full run.

Where are crash logs located?

Server and test logs are saved under tests/pytests/logs; include the path shown in the pytest output when reporting failures.