First release of fluent-asserter

announcements
#1

Hey all,

I just released a new library called fluent-asserter. The library enables developers to write test assertions with a fluent interface, resulting in clean automated tests.

The reasons why I created this library:

  • Testing strategies, practices, and TDD are my favorite parts of software engineering and I wanted to create a cool and open source library in the testing space
  • I know that there are other 3th party libraries solving the same problem, but they are quite inactive and as the Rust ecosystem grows, it would be beneficial for the ecosystem to have a testing library with an active community
  • I do not find the native assertion macros (such as assert_eq) readable, and their error messages are also not clean in my point of view.
  • There is no proper and clean way to write assertions for panicking code. The #[should_panic] attribute has many flaws, for example, unrelated panics can cause a test to pass, or having no possibilities to add additional assertions after the panic has occurred and checked.
  • I am quite new to Rust and I am fascinated by this language and its huge potential, so it was an ideal opportunity for me to get more hands-on experience with the language

The fluent-asserter library contains asserters for the following constructs so far:

  • boolean
  • string
  • hashmap
  • iterator
  • numbers
  • option
  • panicking code
  • result

Here are some examples:

#[test]
fn some_random_examples() {
    assert_that!("Life tastes great!").is_equal_to("Life tastes great!");
    assert_that!("Life tastes great!").has_length(18);

    assert_that!(22).is_in_range(21, 31);
    assert_that!(3.14159f64).is_approx_equal(3.142, 0.001);

    assert_that!(vec![2, 3, 4]).has_count(3);
    assert_that!(vec!["tasty", "delicious", "lovely"]).contains("delicious");
}

One of the coolest feature of the library is to have a panic asserter:

#[test]
fn test_panics_with_message() {
    assert_that_code!(|| panic!("specific panic message"))
        .panics()
        .with_message("specific panic message");
}

The library is far from perfect and there are many things to add to it and to improve on it.

Any feedback on the library is appreciated!

If you want to contribute or do some pair-programming with me on some cool features, hit me up, you can easily reach me on my Twitter account

Thank you for reading it, and have an awesome weekend ahead!

5 Likes
#2

Hi dmoka,

Why would someone will prefer to use such assertions versus simple asserts?

assert_eq!("Life tastes great!", "Life tastes great!");
assert_eq!("Life tastes great!".len(), 18);
assert!((21..31).contains(&22));
assert_eq!(vec![2, 3, 4].len(), 3);
assert!(vec!["tasty", "delicious", "lovely"].contains(&"delicious"));
// Approximate assertion will require to use "approx" crate

To write any test everything you need is assert_eq(expected, actual) (and something for panics).

Using simple assertions have two major advantages:

  1. Standardizes test code
  2. Allows to create standardized automatic test fail reports
#3

To address this issue have you tried pretty_assertions ?

1 Like
#4

I'll add that it's conventional and convenient for reader to put links to crates.io and docs.rs in your README file.

1 Like
#5

Thanks for your message!

Personally, I do not find assert_eq! and assert! fluently readable. I also prefer not to use similar functions in other languages. Although I would not call them totally unreadable, they do the job, but they come with the additional cognitive mental load. As a developer, I am always striving for making the code as readable as possible, and especially the test code.

As for the standardization, you have indeed a good point.

#7

I did not know this, this seems like an awesome library, thanks for mentioning it!

#8

That's a great point, I will add it right away, thank you for pointing it out!

#9

This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.