3 ms·

> That's unfortunate, as testing against "fixed" "expected" outcome is very common, .... so write it in your preferred order then, in your own code? Why is it

> That's unfortunate, as testing against "fixed" "expected" outcome is very common, .... so write it in your preferred order then, in your own code? Why is it "unfortunate" that a generic macro isn't concerned with explicit order? It checks that left == right, [0] no more, no less. Instead of that, I'm free to follow my own conventions when writing tests. [1] [0]: https://doc.rust-lang.org/src/core/macros.rs.html#44 https://doc.rust-lang.org/src/core/macros.rs.html#44 [1]: https://git.sr.ht/~andrewzah/korean_numbers/tree/master/tests/test.rs#L176 https://git.sr.ht/~andrewzah/korean_numbers/tree/master/test...

masklinn 7y ago
Fixing the ordering can provide for clearer error messages and the like, for instance rather than the error message being "foo is different from bar" you could have "got foo, expected bar". However I don't see how you can enforce it especially in a simple function / macro (I guess that's one point for BDD-style interfaces): the expected value is not necessarily static so it's not like you could require a const / static / literal even if the language allowed for such an annotation.
- twic 7y ago
  You can use a form like: assert_that(foo, is_equal_to(bar)); Which makes it sort of clear that foo is the actual value, and bar is the expected. Especially when you also see things like: assert_that(foo, is_not_zero()); Perhaps that's what you mean by 'BDD-style interfaces'.
  - masklinn 7y ago
    > Perhaps that's what you mean by 'BDD-style interfaces'. Yes. It's usually a more OO shape but usually along the lines of `foo.should.be.equal.to(bar)` or somesuch, a "natural" reading makes it pretty likely the parameter is the expected value.
- intertextuality 7y ago
  You could always define a macro like "expect_that", or something similar to ruby's expect(obj).to eq, etc. I find assert_eq!() personally to not be confusing since I always follow the same order, even though I come from a Ruby background with rspec and/or cucumber.

masklinn 7y ago

Fixing the ordering can provide for clearer error messages and the like, for instance rather than the error message being "foo is different from bar" you could have "got foo, expected bar". However I don't see how you can enforce it especially in a simple function / macro (I guess that's one point for BDD-style interfaces): the expected value is not necessarily static so it's not like you could require a const / static / literal even if the language allowed for such an annotation.

twic 7y ago
You can use a form like: assert_that(foo, is_equal_to(bar)); Which makes it sort of clear that foo is the actual value, and bar is the expected. Especially when you also see things like: assert_that(foo, is_not_zero()); Perhaps that's what you mean by 'BDD-style interfaces'.
- masklinn 7y ago
  > Perhaps that's what you mean by 'BDD-style interfaces'. Yes. It's usually a more OO shape but usually along the lines of `foo.should.be.equal.to(bar)` or somesuch, a "natural" reading makes it pretty likely the parameter is the expected value.
intertextuality 7y ago
You could always define a macro like "expect_that", or something similar to ruby's expect(obj).to eq, etc. I find assert_eq!() personally to not be confusing since I always follow the same order, even though I come from a Ruby background with rspec and/or cucumber.