Question about testing design

[azzamsa]

Hi.

I would like to know the decision behind the design of the testing Poem app.
In other frameworks such as Rocket and Warp (I can't try actix for GraphQL because it always fails when compiling), we do not need to configure the app again. We just run the app and test it.

Given the Health handler below:

pub async fn read() -> FieldResult<Health> {
    let health = Health {
        status: "running".to_string(),
    };
    Ok(health)
}

We can test it using Rocket simply by running the app via Client::tracked and running the request to desired endpoint:

#[test]
fn health() -> Result<()> {
    let client = Client::tracked(asr::rocket())?;
    let query = HealthQuery::build(());

    let resp = client
        .post("/graphql")
        .header(ContentType::JSON)
        .json(&query)
        .dispatch();

    assert_eq!(resp.status(), Status::Ok);

    let health_response = resp
        .into_json::<HealthResponse>()?
    assert_eq!(health_response.data.health.status, "running");

    Ok(())
}

It's a similar thing with Warp.

#[tokio::test]
async fn health() -> Result<()> {
    dotenv().ok();
    let client = app::serve();

    let query = HealthQuery::build(());
    let resp = request()
        .method("POST")
        .path("/graphql")
        .json(&query)
        .reply(&client)
        .await;

    assert_eq!(resp.status(), StatusCode::OK);

    let health_response: HealthResponse = from_slice(resp.body())?;
    assert_eq!(health_response.data.health.status, "running");

    Ok(())
}

I don't have a real test code in actix, but looking at my old actix REST API test codebase. It looks similar to Poem.
We need to set up and configure the app first.

#[actix_rt::test]
async fn test_health() {
    let mut app = test::init_service(App::new().configure(health::init)).await;
    let resp = test::TestRequest::get()
        .uri("/health")
        .send_request(&mut app)
        .await;

    let body: health::Health = test::read_body_json(resp).await;
    assert_eq!(body.status, "running");
}

This is not a head-to-head comparison, since it is a test for REST API. But I get the idea. Both Poem and Actix need to configure and set up the app before a test.

#[tokio::test]
async fn health() -> Result<()> {
  // ⚠️ too many additional steps
    let app = Route::new().at("/", graphql_handler);
    let client = TestClient::new(app);

   // ⚠️ too many additional steps
    let db_pool = db::get_pool().expect("failed to get db pool");
    let schema = Schema::build(Query::default(), Mutation::default(), EmptySubscription)
        .data(db_pool)
        .finish();

    let query = HealthQuery::build(());
    let resp = client.post("/").data(schema).body_json(&query).send().await;

    let resp_str = resp.into_body().into_string().await?;
    let health_response: HealthResponse = serde_json::from_str(&resp_str)?;
    assert_eq!(health_response.data.health.status, "running");

    Ok(())
}

Thus it needs many additional ceremonies before doing the tests. In Rust, we don't have something such as conftest.py for Python Pytest.
Doing setup-and-teardown is painful. Sometimes the teardown is skipped because the test function is panicked.

That's why I just make each of my integration tests is independent. I am afraid this means I need to do many setup-and-configure db pool, graphql schema in each test function.

Would you like to share the decision behind this?

Thanks for Poem.

[sunli829]

These are not additional steps.

Consider you create an application, you need to create a route and add some context data, such as a database connection, and add some middleware.

fn create_app() -> impl Endpoint {
    let dbpool = create_db_pool();
    Route::new().at("/a", a)
        .at("/b", b)
        .at("/c", c)
        .with(middleware1)
        .with(middleware2)
        .data(dbpool);
}

// start the server
let app = create_app();
Server::new(TcpListener::bind("127.0.0.1:3000"))
        .run(app)
        .await

// test /a
#[tokio::test]
async fn test_a() {
    let app = create_app();
    let client = TestClient::new(app);
    client.get(...).send().await.assert_status_is_ok();
}

[sunli829]

In Poem, all types that can handle HTTP requests implement Endpoint, such as routes, handlers, and TestClient can test any endpoint, it is more powerful and flexible than you think. It can test both the entire application and parts of it.

[sunli829]

You can also write a unit test.

#[handler]
async fn a() -> String {
 ....
}

// test /a
#[tokio::test]
async fn test_a() {
    let client = TestClient::new(a);
    client.get(...).send().await.assert_status_is_ok();
}

[azzamsa]

Nice and Clear.

Maybe the lack of experience makes me come up with this question.
Now I understand, Even though I need to do setup-and-configure. It gives me much more flexibility.
I just saw Axum had similar behavior.

Given this design, I can test part of the app, and I can avoid many unnecessary mocking. Since I can control how the app would behave
from the test function.

Thanks a lot for Poem.