axum-login icon indicating copy to clipboard operation
axum-login copied to clipboard

add test to sqlite example

Open thor314 opened this issue 11 months ago • 3 comments

Adding a login-logout test to the sqlite example.

Several questions arose while implementing the test:

  • How to build the login request, to include cookies(*) like AuthSession and Messages in the request
  • How to verify that the user is logged in
  • Why logout is a GET request instead of a POST in these examples

these questions are documented in the test:

#[sqlx::test]
async fn test_login_logout(pool: SqlitePool) {
    let app = setup_app(pool).await.unwrap();

    let login_request = {
        let credentials = Credentials {
            username: "ferris".to_string(),
            password: "password".to_string(),
            next: None,
        };
        // todo: unclear how to instatiate or add to request; no tests in axum-messages
        // let messages: Messages;
        let credentials = serde_urlencoded::to_string(credentials).unwrap();

        Request::builder()
            .uri("/login")
            .method("POST")
            .header(CONTENT_TYPE, "application/x-www-form-urlencoded")
            // todo: where do I put messages in the request?
            .body(credentials)
            .unwrap()
    };
    let login_response = app.clone().oneshot(login_request).await.unwrap();
    dbg!(&login_response);
    assert!(login_response.status().is_redirection());

    // todo: how to verify that the user is logged in?

    // why is logout a get request instead of a post in the example?
    let logout_request = Request::builder()
        .uri("/logout")
        .method("GET")
        .body(Body::empty())
        .unwrap();
    let logout_response = app.clone().oneshot(logout_request).await.unwrap();
    dbg!(&logout_response);
    assert!(logout_response.status().is_redirection());
}

thor314 avatar Mar 26 '24 18:03 thor314

Thanks for putting this together!

I'm curious how this is different from the integration tests and why we wouldn't continue to colocate tests in that directory?

maxcountryman avatar Mar 26 '24 18:03 maxcountryman

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 80.13%. Comparing base (e959752) to head (07236bf).

:exclamation: Current head 07236bf differs from pull request most recent head af69d00. Consider uploading reports for the commit af69d00 to get more accurate results

Additional details and impacted files
@@           Coverage Diff           @@
##             main     #208   +/-   ##
=======================================
  Coverage   80.13%   80.13%           
=======================================
  Files           5        5           
  Lines         151      151           
=======================================
  Hits          121      121           
  Misses         30       30           

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

codecov[bot] avatar Mar 26 '24 18:03 codecov[bot]

I think your question is why bother with unit tests for a server, as opposed to only integration tests, please correct me if otherwise.

Integration tests are useful for testing the overall function of a server. Unit tests are closer to sanity checks, that some component is functioning as expected.

I am currently debugging where axum-login is breaking within my own server, and these sanity checks help me reason with finer granularity as to whether I have made mistakes, or if something is broken in the library (I don't yet know which may be the case).

In either case, unit tests are at least an additionally helpful documentation, and especially helpful for the kind of sanity I currently feel to lack in my debugging.

thor314 avatar Mar 26 '24 18:03 thor314

I'd prefer this kind of thing be done in a separate repo and that we continue to use the test harness that's already in place for axum-login and its examples.

maxcountryman avatar Jul 18 '24 18:07 maxcountryman