Adding the semantics of swap, insertion or deletion.

This feature should be able to be turned on/off by feature.

Example 1:

assert_that!(vec![1,4,3,2]).contains_exactly_in_order(vec![1,2,3,4]);

Idea of better message:

contents match, but order was wrong
---
expected: [1, 2, 3, 4]
actual  : [1, <bold>4</bold>, 3, <bold>2</bold>]

Example 2:

assert_that!(vec![1, 3, 4, 5]).contains_exactly_in_order(vec![1,2,3,4]);

Idea of better message:

contents match, but order was wrong
---
expected: [1, <green>2</green>, 3, 4]
actual  : [1,<space/>           3, 4, <red>5</red>]

Color usage guideline: Green should emphasize the normal case, and red should emphasize the unexpected case, imo.

Estimation/design: This needs quite big structural change in Fact struct. Specifically, more semantic structs may need to be defined to represent added or deleted object, because generating Fact should be decoupled from formatting in order to change the formatting logic in runtime.

When trying to run cargo build in the assertor repository, the following error message is displayed:

error: impl method assumes more implied bounds than the corresponding trait method
   --> src/assertions/map.rs:171:16
    |
171 |     fn key_set(&self) -> Subject<'a, Keys<K, V>, (), R> {
    |                ^^^^^     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ help: replace this type to make the impl signature compatible: `Subject<'_, std::collections::hash_map::Keys<'_, K, V>, (), R>`
    |
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #105572 <https://github.com/rust-lang/rust/issues/105572>
    = note: `#[deny(implied_bounds_entailment)]` on by default

error: could not compile `assertor` due to 2 previous errors

Expected Behavior
cargo build should compile the assertor repository successfully without any errors.

Actual Behavior
The build process fails with the error message described above.

Steps to Reproduce
Clone the assertor repository from GitHub: git clone https://github.com/google/assertor.git
Navigate to the assertor directory: cd assertor
Run cargo build

Additional Information
assertor version: v0.0.1
Operating System: Ubuntu 22.04
Rust: 1.68.2

Possible Solution
It looks like the error is related to the key_set method implementation in map.rs. The error message suggests replacing Subject<'a, Keys<K, V>, (), R> with Subject<', std::collections::hash_map::Keys<', K, V>, (), R> in the method signature to make it compatible with the trait method.

Derived from #30.

Current formatting logic for different values can be ugly in some case; specifically 1) when formatted string length of key is quite long, 2) the formatted string length of values are quite long, 3) there are many diffs.

Current:

key {:?} was mapped to an unexpected value
expected value {:?}, but found {:?}

Improvement idea from this comment

keys were mapped to an unexpected values: [
  "key1": {
    "expected" : "val1",
    "actual"      : "val2" 
  }
  ...
]

Hey 👋🏾

I really like the fluid syntax of this library. While working with it, a few assertions would be great to have. Some of them are for ergonomics when working with enumeration variants. Like simple matching. So I could imagine for example something like:

enum Color {
   RED,
   GREEN,
   BLUE,
   RGB(u8, u8, u8),
}

assert_that!(Color::RED).matches(Color::RED);
assert_that!(Color::RGB(255, 0, 0)).matches(Color::RGB(_, _, _));
assert_that!(Color::RGB(255, 0, 0)).matches(Color::RGB(_, _, 0));

With the "default" API you can write these simply with assert!(matches!(...)). But then we have the syntax of the assertor it's assert_that! mixed with the other. Which does not read and feel great. So I though it might be easy enough to add this? 🙈

In any case: thanks for this library. Like it so far!

And also other setups for CI for better development.

Map and Vec have a very decent support at this point. However, sorted/heap types (BTreeMap, BTreeSet) are lacking because we have no way to verify both ordering/sequencing and presence of map entries. I would like to add support for BTreeMap (separate from Map) and BTreeSet (separate from Set).

For objects having long Debug outputs, current debug message is messed up.

One improvable idea is

Example:

#[derive(Debug, PartialEq)]
struct LongDebugObject<> {
    values: Vec<&'static str>,
    another_value: Option<&'static str>,
}


let actual = vec![
    LongDebugObject {
        values: vec!["a", "c", "t", "u", "a", "l"],
        another_value: None,
    },
    LongDebugObject {
        values: vec![],
        another_value: Some("same value"),
    },
];
let expected = vec![
    LongDebugObject {
        values: vec![],
        another_value: Some("same value"),
    },
    LongDebugObject {
        values: vec!["e", "x", "p", "e", "c", "t", "e", "d"],
        another_value: None,
    },
];
assert_that!(actual).contains_exactly_in_order(expected);

Current

missing (1)   : [LongDebugObject { values: ["e", "x", "p", "e", "c", "t", "e", "d"], another_value: None }]
unexpected (1): [LongDebugObject { values: ["a", "c", "t", "u", "a", "l"], another_value: None }]
---
expected      : [LongDebugObject { values: [], another_value: Some("same value") }, LongDebugObject { values: ["e", "x", "p", "e", "c", "t", "e", "d"], another_value: None }]
actual        : [LongDebugObject { values: ["a", "c", "t", "u", "a", "l"], another_value: None }, LongDebugObject { values: [], another_value: Some("same value") }]

Improvement Idea

Make the output of expected / actual values multiple lines instead of single line.

missing (1)   : [LongDebugObject { values: ["e", "x", "p", "e", "c", "t", "e", "d"], another_value: None }]
unexpected (1): [LongDebugObject { values: ["a", "c", "t", "u", "a", "l"], another_value: None }]
---
expected      :  [
   - LongDebugObject { values: [], another_value: Some("same value") }
   - LongDebugObject { values: ["e", "x", "p", "e", "c", "t", "e", "d"], another_value: None }
]
actual        : [
   - LongDebugObject { values: ["a", "c", "t", "u", "a", "l"], another_value: None },
   - LongDebugObject { values: [], another_value: Some("same value") }
]

Hello everyone!
I have a few questions about this project:

• This project seems to be the only crate for fluent assertion in rust and I would love to understand in order to contribute. Could we possibly start creating some issues in order to group some features to implement?
• I saw there is a section into the readme.md file that indicates some features, are they still not implemented?
  Thanks in advance for your time