Lint for denylisted-strings, similar to denylisted-names

[clarfonthey]

This would search for specific string literals that are blacklisted, for example "foo", "bar", or "123".

[oli-obk]

Do you have examples of string literals to block? Do you mean "foo" and similar?

[clarfonthey]

Currently, just the ones from the existing lint: foo, bar, etc. Could also add "123."

[shssoichiro]

If this is added, I wouldn't want it to be turned on by default. I use "foo" and "bar" all over the place in my tests, and I do run clippy on my test code.

[clarfonthey]

I mean, it already applies for variable names, this would just apply it for strings too. The idea is that your tests should use strings other than the most common ones.

[shssoichiro]

Let's say I have a test for a JSON API that looks like this:

#[test]
fn create_session_success() {
    let conn = DB_POOL.get().unwrap();
    let mut user = NewUser::new("[email protected]", "correcthorsebatterystaple", "Foo Bar").save(&*conn);
    user.status = User::STATUS_ACTIVE;
    user.update(&*conn);

    let rocket = api::build_rocket();
    let req_body = json!({
        "email": "[email protected]",
        "password": "correcthorsebatterystaple"
    });
    let mut req = MockRequest::new(Method::Post, "/api/sessions")
        .header(ContentType::JSON)
        .body(&req_body.to_string());
    let mut response = req.dispatch_with(&rocket);
    assert_eq!(response.status(), Status::Ok);
    let resp_body: HashMap<String, Value> =
        serde_json::from_str(&response.body().and_then(|b| b.into_string()).unwrap()).unwrap();
    assert!(resp_body.contains_key(&"token".to_string()));
}

What would be the benefit to using strings other than "foo" and "bar", if I just want to ensure that all of the fields are filled in and valid? I can see the benefit for variable names--the code becomes harder to understand if I rename user to foo--but I don't see the benefit for strings.

[oli-obk]

We should disable this and many other lints if cfg test is on

[clarfonthey]

I've updated the OP to describe this a bit better.