-
-
Notifications
You must be signed in to change notification settings - Fork 64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Document & refactor Stelline a bit #433
base: main
Are you sure you want to change the base?
Changes from all commits
e4cd6df
aa78c1d
27a93f6
678aa7f
279da67
9daef8a
2fabae5
41bc25d
3a5f18c
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -175,3 +175,5 @@ pub mod validate; | |
pub mod validator; | ||
pub mod zonefile; | ||
pub mod zonetree; | ||
|
||
mod logging; |
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,21 @@ | ||
//! Common logging functions | ||
|
||
/// Setup logging of events reported by domain and the test suite. | ||
/// | ||
/// Use the RUST_LOG environment variable to override the defaults. | ||
/// | ||
/// E.g. To enable debug level logging: | ||
/// | ||
/// ```bash | ||
/// RUST_LOG=DEBUG | ||
/// ``` | ||
#[cfg(feature = "tracing-subscriber")] | ||
pub fn init_logging() { | ||
Check warning on line 13 in src/logging.rs GitHub Actions / Build examples (1.78.0)
Check warning on line 13 in src/logging.rs GitHub Actions / Build examples (1.78.0)
Check warning on line 13 in src/logging.rs GitHub Actions / Build examples (1.78.0)
Check warning on line 13 in src/logging.rs GitHub Actions / Build examples (1.78.0)
Check warning on line 13 in src/logging.rs GitHub Actions / Build examples (stable)
Check warning on line 13 in src/logging.rs GitHub Actions / Build examples (stable)
Check warning on line 13 in src/logging.rs GitHub Actions / Build examples (stable)
Check warning on line 13 in src/logging.rs GitHub Actions / Build examples (stable)
Check warning on line 13 in src/logging.rs GitHub Actions / Build examples (beta)
Check warning on line 13 in src/logging.rs GitHub Actions / Build examples (beta)
Check warning on line 13 in src/logging.rs GitHub Actions / Build examples (beta)
Check warning on line 13 in src/logging.rs GitHub Actions / Build examples (beta)
Check warning on line 13 in src/logging.rs GitHub Actions / Build examples (nightly)
Check warning on line 13 in src/logging.rs GitHub Actions / Build examples (nightly)
Check warning on line 13 in src/logging.rs GitHub Actions / Build examples (nightly)
|
||
use tracing_subscriber::EnvFilter; | ||
tracing_subscriber::fmt() | ||
.with_env_filter(EnvFilter::from_default_env()) | ||
.with_thread_ids(true) | ||
.without_time() | ||
.try_init() | ||
.ok(); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this needs to be worded differently. A query is "sent" (sort of, more on that in a minute) but I'm not sure if it goes to the "tested program", that depends on what you mean by "tested program".
Stelline tests consists of several parts:
Stelline tests broadly fall into two categories, real client with mock responses, or real/simple client with real responses, or even a mix of both (see https://github.com/NLnetLabs/domain/blob/xfr/test-data/server/secondary_zone_lifecycle.rpl).
Examples of real clients with mock responses can be seen in the /tests/net-client*.rs tests. Each test creates a real client and connects it to the Stelline mock response "server" by using a Stelline mock
Dgram
connection that allows the Stelline runner to capture the requests and reply using responses from the .rpl script. These tests use the "do_client_simple()" "runner".Examples of real clients with real responses can be seen in src/net/server/tests/integration.rs. The server_tests() fn runs tests using test-data/server/*.rpl recipe/replay scripts using the "do_client()" "runner". This runner dispatches requests using a factory supplied by the test function. The factory helps it select the right kind of client for the test, e.g. UDP, TCP, using a TSIG key or not, etc. This runner also has logic for handling large mutli-response answers such as occur with XFR. The test also does much more setup work than the client only tests as it sets up a real server that will receive requests via a mock network connection and respond to them (based on how it was configured by the test based on the .rpl file config block). The server tests and "do_client" runer also support mixing real and mock servers which is just a matter of using the right mock network connection (a connection to a real server, or a connection to the Stelline mock response "server"). Some of these tests also use a different "simple" client (defined in src/stelline/simple_dgram_client.rs) which is a real client but interferes as little as possible with the request and the response so that Stelline tests can test additional things.
So, back to the start. Does a request get "sent". Yes as far as the client code but no actual network activiity occurs, not even localhost. And what is the "tested program"? It's either the Stelline framework itself which receives the request and replies per the .rpl script, or it's a real server created by the test function.
So, your comment isn't wrong, but I'm wondering how and where we can capture these details, and how to hint in higher level docs at these different use cases and supporting logic.