Skip to content

Design Document on improving the Drasi E2E test framework #13

Open
ruokun-niu wants to merge 15 commits into
drasi-project:mainfrom
ruokun-niu:test-framework
Open

Design Document on improving the Drasi E2E test framework #13
ruokun-niu wants to merge 15 commits into
drasi-project:mainfrom
ruokun-niu:test-framework

Conversation

@ruokun-niu
Copy link
Copy Markdown
Contributor

Description

This PR introduces a design document on areas that we can improve/update the Drasi E2E test framework with (better) support for Lib and Server

Type of change

  • This pull request fixes a bug in Drasi and has an approved issue (issue link required).
  • This pull request adds or changes features of Drasi and has an approved issue (issue link required).
  • This pull request is a minor refactor, code cleanup, test improvement, or other maintenance task and doesn't change the functionality of Drasi (issue link optional).

Fixes: #issue_number

Signed-off-by: ruokun-niu <ruokunniu@gmail.com>
Signed-off-by: ruokun-niu <ruokunniu@gmail.com>
Signed-off-by: ruokun-niu <ruokunniu@gmail.com>
Signed-off-by: ruokun-niu <ruokunniu@gmail.com>
Signed-off-by: ruokun-niu <ruokunniu@gmail.com>
Signed-off-by: ruokun-niu <ruokunniu@gmail.com>
Signed-off-by: ruokun-niu <ruokunniu@gmail.com>
Copilot AI review requested due to automatic review settings May 19, 2026 20:19
Copy link
Copy Markdown

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR adds a new design document proposing improvements to the Drasi E2E test framework, with a focus on better supporting drasi-lib and drasi-server execution modes and reducing config duplication across target variants.

Changes:

  • Adds a “Test Framework Plan” document describing current ETF execution patterns (drasi-lib in-process, drasi-server standalone, drasi-platform on Kubernetes) and CI/run workflows.
  • Proposes a new configuration model that splits test scenario definition (test-config.yaml) from target-specific runtime patterns (pattern files) and describes how the framework merges them.
  • Outlines an expanded test suite scope (indexes, failure recovery), reporting approach, and test data hosting considerations.

Comment on lines +1 to +5
# Test Framework Plan

* Project Drasi — April 29, 2026 — Ruokun Niu (@ruokun-niu)

## Test Framework Requirements
## Test Framework Requirements


**Runnable manually.** Developers must be able to run the full test suite from their local machine or as a Github Actions workflow (triggered via `workflow_dispatch`). The existing building_comfort examples in the [test-infra](https://github.com/drasi-project/test-infra) repo demonstrate three distinct run patterns:
**Runnable manually.** Developers must be able to run the full test suite from their local machine or as a Github Actions workflow (triggered via `workflow_dispatch`). The existing building_comfort examples in the [test-infra](https://github.com/drasi-project/test-infra) repo demonstrate three distinct run patterns:

- **drasi-lib (in-process):** A single shell script runs the test-service with drasi-lib compiled in — no external processes needed. The script invokes `cargo run --release --manifest-path ./test-service/Cargo.toml -- --config <config.json>` from the `e2e-test-framework` directory. Everything runs in one process.
- **Drasi Server (standalone):** A shell script first builds and starts the drasi-server binary (from a sibling `../../drasi-server` directory) with a `server-config.yaml`, waits for its health check, and then starts the test-service with a separate `config.json` that dispatches changes via HTTP or gRPC to the running server. Currently it can use either a prebuilt binary or execute `cargo run` from a `drasi-server` repo. It is also worthing noting that we have four variants of the drasi-server pattern: http, http adaptive, grpc and grpc adaptive.
Comment on lines +173 to +176
#### Proposed Changes

The goal is to have a single central test config per test scenario that works with any Drasi target. The test config defines the "what" (test ID, data model, queries, stop criteria), and a separate pattern file defines the "how" (dispatchers, handlers, engine/server config, runtime settings). The ETF merges them at load time.

Comment on lines +361 to +363
- **Hugging Face Hub (recommended for test data files):** Public datasets on Hugging Face are freely downloadable without authentication and without the rate limiting issues of GitHub's API. Files are accessible via a predictable HTTP URL pattern: `https://huggingface.co/datasets/{org}/{repo}/resolve/main/{path}`. We would create a public dataset repo (e.g., `drasi-project/test-data`) and push JSONL files to it. HF Hub is git-based and automatically uses Git LFS for large files, so versioning is built in. The ETF would download files with a simple HTTP GET to the resolve URL — no special client library needed. This is free, public, requires no infrastructure to maintain, and has no rate limits for normal usage.

The recommended approach is: **test configs and golden files in the repo** (LocalStorage), **JSONL test data files on Hugging Face Hub** (downloaded via HTTP at test time or pre-cached locally). The ETF would need a small addition to support fetching data from an HTTP URL — either a new `HuggingFace` backend or a generic `HttpDownload` backend that accepts a base URL and file paths. Alternatively, a shell script in the test setup phase could pre-download the data into the local data store path before the ETF starts.
Signed-off-by: ruokun-niu <ruokunniu@gmail.com>
Signed-off-by: ruokun-niu <ruokunniu@gmail.com>
Signed-off-by: ruokun-niu <ruokunniu@gmail.com>
Signed-off-by: ruokun-niu <ruokunniu@gmail.com>
Signed-off-by: ruokun-niu <ruokunniu@gmail.com>
Signed-off-by: ruokun-niu <ruokunniu@gmail.com>
Signed-off-by: ruokun-niu <ruokunniu@gmail.com>
Signed-off-by: ruokun-niu <ruokunniu@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants