Skip to content
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

DO NOT MERGE test(subscriber): additional testing of integration tests on CI #458

Closed
wants to merge 2 commits into from

Commits on Aug 1, 2023

  1. test(subscriber): add initial integration tests

    The `console-subscriber` crate has no integration tests. There are some
    unit tests, but without very high coverage of features.
    
    Recently, we've found or fixed a few errors which probably could have
    been caught by a medium level of integration testing.
    
    However, testing `console-subscriber` isn't straight forward. It is
    effectively a tracing subscriber (or layer) on one end, and a gRPC
    server on the other end.
    
    This change adds enough of a testing framework to write some initial
    integration tests. It is the first step towards closing #450.
    
    Each test comprises 2 parts:
    - One or more "expcted tasks"
    - A future which will be driven to completion on a dedicated Tokio runtime.
    
    Behind the scenes, a console subscriber layer is created and it's server
    part is connected to a duplex stream. The client of the duplex stream
    then records incoming updates and reconstructs "actual tasks". The layer
    itself is set as the default subscriber for the duration of `block_on`
    which is used to drive the provided future to completioin.
    
    The expected tasks have a set of "matches", which is how we find the
    actual task that we want to validate against. Currently, the only value
    we match on is the task's name.
    
    The expected tasks also have a set of expectations. These are other
    fields on the actual task which are validated once a matching task is
    found. Currently, the two fields which can have expectations set on them
    are the `wakes` and `self_wakes` fields.
    
    So, to construct an expected task, which will match a task with the name
    `"my-task"` and then validate that the matched task gets woken once, the
    code would be:
    
    ```rust
    ExpectedTask::default()
        .match_name("my-task")
        .expect_wakes(1);
    ```
    
    A future which passes this test could be:
    
    ```rust
    async {
        task::Builder::new()
            .name("my-task")
            .spawn(async {
                tokio::time::sleep(std::time::Duration::ZERO).await
            })
    }
    ```
    
    The full test would then look like:
    
    ```rust
    fn wakes_once() {
        let expected_task = ExpectedTask::default()
            .match_name("my-task")
            .expect_wakes(1);
    
        let future = async {
            task::Builder::new()
                .name("my-task")
                .spawn(async {
                    tokio::time::sleep(std::time::Duration::ZERO).await
                })
        };
    
        assert_task(expected_task, future);
    }
    ```
    
    The PR depends on 2 others:
     - #447 which fixes an error in the logic that determines whether a task
       is retained in the aggregator or not.
     - #451 which exposes the server parts and is necessary to allow us to
       connect the instrument server and client via a duplex channel.
    
    This change contains some initial tests for wakes and self wakes which
    would have caught the error fixed in #430. Additionally there are tests
    for the functionality of the testing framework itself.
    hds committed Aug 1, 2023
    Configuration menu
    Copy the full SHA
    42fb829 View commit details
    Browse the repository at this point in the history

Commits on Aug 18, 2023

  1. Configuration menu
    Copy the full SHA
    2b1ba72 View commit details
    Browse the repository at this point in the history