Testing helps catch regressions as a Rust web application changes. Pair automated handler tests with live checks of the running server. section 1.3.2 section 2.3.5
A practical API-testing loop:
- Construct the request data or URL parameters and the application state the handler needs. section 3.2.4 section 3.2.5
- Call the handler in an asynchronous test and assert the response status. section 3.2.4 section 3.2.5
- Run the server and exercise endpoints with curl or a browser; inspect returned content and headers. section 2.3.5 section 3.2.4
Listing 3.8 Test script for posting a new course
#[cfg(test)] #1
mod tests { #2
use super::*; #3
use actix_web::http::StatusCode;
use std::sync::Mutex;
#[actix_rt::test] #4
async fn post_course_test() {
let course = web::Json(Course { #5
tutor_id: 1,
course_name: "Hello, this is test course".into(),
course_id: None,
posted_time: None,
});
let app_state: web::Data<AppState> = web::Data::new(AppState { #6
health_check_response: "".to_string(),
visit_count: Mutex::new(0),
courses: Mutex::new(vec![]),
});
let resp = new_course(course, app_state).await; #7
assert_eq!(resp.status(), StatusCode::OK); #8
}
}
The test sets up a course payload and application state, then invokes the handler in an Actix async test. section 3.2.4
Test more than one route
Tests exercise course creation, retrieval of a tutor’s courses, and retrieval of one course. Live checks also cover static pages, JSON responses, health, and an invalid path. section 3.2.4 section 3.2.5 section 3.2.6 section 2.3.5
Treat these tests as demonstrations, not exhaustive coverage: real-world tests should address more success and failure scenarios. section 3.2.6
