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

Add support to be able to test the route tree using match_pattern and match_name. #3286

Open
Lalit3716 opened this issue Feb 12, 2024 · 2 comments

Comments

@Lalit3716
Copy link

Lalit3716 commented Feb 12, 2024

So currently the test requests does not seem to implement the match functions - match_pattern/match_name.
Consider the below app having two services:

#[get("/hello/{name}", name = "greet")]
async fn greet(name: web::Path<String>) -> impl Responder {
    format!("Hello {name}!")
}

#[get("/hello/me", name = "greet_me")]
async fn greet_me() -> impl Responder {
    format!("Hi Developer!")
}

And a test like this:

    #[actix_web::test]
    async fn test_index_get() {
        let _app = test::init_service(App::new().service(greet).service(greet_me)).await;
        let req = test::TestRequest::get()
            .uri("/hello/john")
            .insert_header(ContentType::plaintext())
            .to_srv_request();

        println!("{:?}", req.match_pattern());
        println!("{:?}", req.match_name());
        assert!(true);
    }

Expected Behavior

match_pattern should print the matching route url/path, in this case: "/hello/{name}"
match_name should print the given name to the service, in this case: "greet"

Current Behavior

Both match_pattern and match_name returns None.

Context

We can use these functions to test if the user has registered the services in the correct order as he/she intended and the user requests are in fact routing to correct handlers.

Currently, if user had registered the greet service before greet_me service and a user sends the request to /hello/me it will send "Hello me!`` whereas it should have returned "Hi Developer!".
That's what we wanted to test, Additional Context: qdrant/qdrant#3547.

Your Environment

  • Rust Version: rustc 1.75.0 (82e1608df 2023-12-21)
  • Actix Web Version: 4
@HappyPotatoman
Copy link

Hey, how about adding a clippy warning to catch and warn in cases like this.

I assume the real pain happens if the developer doesn't realize some path is unreachable due to a match all pattern matched before the target path.

@Lalit3716
Copy link
Author

Yeah giving a warning about unreachable routes sounds good to me.

And yeah exactly this-

Hey, how about adding a clippy warning to catch and warn in cases like this.

I assume the real pain happens if the developer doesn't realize some path is unreachable due to a match all pattern matched before the target path.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants