Use expectest for test expectations

[brendanzab]

Expectest makes tests cleaner and gives better errors. I've used it before and it's quite nice! Might be something to look into.

[Marwes]

I have used something similar for JavaScript and I agree that it can give better error messages. I think there is some room for caution though. Most tests atm are just assert_eq which is much more familiar for most people

[brendanzab]

I guess I've just been infected with RSpec at work!

[brendanzab]

We might be also able to make our own matchers, say for unification etc..

[Marwes]

That's nice problem to have!

[Marwes]

We might be also able to make our own matchers, say for unification etc..

That would be very useful. The current tests which assert on types with type variables are very brittle

[brendanzab]

RSpec has plenty of problems (crazy dynamic scoping for one), but it certainly makes test setup/teardown and pretty printing very nice.

[swr1bm86]

@Marwes you mean we should assert the equality between types not the strings here right?

That would be very useful. The current tests which assert on types with type variables are very brittle

[Marwes]

Yes, since PartialEq<Type<_, _>> only checks for exact equality tests like https://github.com/Marwes/gluon/blob/51b85f44b6a2939714d40daf0d6fc67704f76c6d/check/tests/pass.rs#L385 can start failing if the automatic generation of variables just change a little bit. It would be better to have an equvality check which succeed on a -> b == a0 -> b0 (but not a -> a == a0 -> b0).

Since this requires some sort of state to track it, it might be best to keep that logic out of the standard equality comparison however. Either with a matcher as in expectest or with a newtype.

Pseudo code:

pub struct Unify<'a, I, T>(&'a Type<I, T>);
impl PartialEq<Unify<'a, I, T> for Type<I, T> { .. }

assert_eq(actual_type, Unify(expected_type));