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

Small wording/naming changes; some missing tests #15

Merged
merged 13 commits into from
Mar 12, 2025

Conversation

helixbass
Copy link
Contributor

Hi, these are some changes I noticed as I read through the code-base

Thanks for the great library, it has become something I reach for when I'm writing tests in Rust!

I'll comment on the individual changes in the PR diff

@@ -86,8 +86,8 @@ where

if subject.is_empty() {
AssertionFailure::from_spec(self)
.with_expected("an non empty hashmap".to_string())
.with_actual(format!("a hashmap with length <{:?}>", subject.len()))
.with_expected("a non empty hashmap".to_string())
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This sounds grammatically more correct

.with_expected("an non empty hashmap".to_string())
.with_actual(format!("a hashmap with length <{:?}>", subject.len()))
.with_expected("a non empty hashmap".to_string())
.with_actual("an empty hashmap".to_string())
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems a little more expected than always saying "with length <0>"?

There are similar changes to this expected/actual failure message change below for HashSet and Vec/&Vec

@@ -340,7 +340,7 @@ mod tests {
// Unfortunately the order of the keys can change. Doesn't seem to make sense to sort them
// just for the sake of checking the panic message.
#[should_panic]
fn should_not_panic_if_hashmap_does_not_contain_key() {
fn should_panic_if_hashmap_does_not_contain_key() {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Renamed a couple tests where the name didn't seem to exactly match what the test was doing

@@ -358,7 +358,7 @@ where
AssertionFailure::from_spec(spec)
.with_expected(format!("Completed iterator (read <{:?}>)", read_expected))
.with_actual(format!(
"Iterator item of <{:?}> (read <{:?}>",
"Iterator item of <{:?}> (read <{:?}>)",
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These looked like missing closing )'s

@@ -166,7 +166,7 @@ mod tests {
}

#[test]
#[should_panic(expected = "\n\texpected: option[none]\n\t but was: option<\"Hello\"")]
#[should_panic(expected = "\n\texpected: option[none]\n\t but was: option<\"Hello\">")]
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not like this was "wrong" but seems more expected to include the closing > in the expected panic message

#[test]
#[should_panic(expected = "\n\texpected: vec to have length <1>\n\t but was: <3>")]
fn should_panic_if_ref_vec_length_does_not_match_expected() {
let test_vec = vec![1, 2, 3];
assert_that(&&test_vec).has_length(1);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

My understanding is that this second failed assertion inside a #[should_panic] test wasn't actually being "exercised" because the test would (expectedly) fail as of the first failed assertion

So split these into two separate tests

assert_that(&&vec![1]).is_empty();
}

#[test]
fn should_not_panic_if_vec_was_expected_to_be_not_empty_and_is() {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looked like tests for .is_not_empty() were missing so added

@oknozor oknozor merged commit 52b2070 into oknozor:main Mar 12, 2025
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

Successfully merging this pull request may close these issues.

2 participants