I don’t believe these functions are even needed.
The language is explicit and I feel when you get familiar with it you gonna realize you can do a lot more with a lot less.
The benefit of a = b, where a is the approximation of the return value of function x is more scannable (for me) given the roots in the mathematical notation, rather than you have to figure out what function y is asserting.
assert_copy has wrong name, but the idea is simple, it is equivalent to:
match_keys = Enum.sort(Map.keys(match))
original_keys = Enum.sort(Map.keys(original))
assert a_keys == b_keys
for key <- match_keys -- (Keyword.keys(except) ++ ignoring) do
assert Map.fetch!(match, key) == Map.fetch!(original, key)
end
for {key, value} <- except do
assert Map.fetch!(match, key) == value
end
In other words - it checks whether the match has the same structure and fields as origin ignoring ignoring fields and ensuring that except fields are matched exactly as is. This is useful for example when testing functions that return data from DB after updates, to check that only thing that has changed are the provided fields and no other field.
But yes, naming is poor.
@devonestes It’s true that the output of assert_fields doesn’t get the coloring, so you can see this:
I’ve thought of hooking into the differencing machinery, but honestly what I’d do is add an assert:
and type ^C-,-a in Emacs to rerun the single test and see:
Sort of a philosophical thing: when an unexpected failure pops you into a test and corresponding code, it’s no reflection on either if you have to spend a minute or two tweaking it to reveal more information.
(Aside: I’ve long noticed that people have different standards for tests and code. For example, people feel that changing tests is somehow more burdensome than changing code. And adding the above seems wronger than sticking an IO.inspect into the failing code, even though they’re really the same sort of thing.
(I feel the same way, but it’s one of the many gut reactions I’ve trained myself out of.)
Regarding using predicates in assert_fields:
I took that from my Clojure testing library. People seem to like it. I’m guessing that they do what I do: hardly ever compare two functions for equality. And when they do, they do the equivalent of:
assert struct1.f == struct2.f
After all, a notion of “extended equality” doesn’t prevent anyone from using plain equality.
I don’t like the assert_copy name either, but I haven’t been able to think of a better one. assert_match, for example, says “regular expression” to me.
I grant that the name assumes before-and-after comparisons of the “same” data. But Repo.update is far from an unusual function: lots of them transform input structures into output structures.
assert_approximately is maybe better, but it’s awfully long.
Meta:
I was an early adopter of Ruby. In one of the early RubyConfs, maybe the first one, Matz said:
Perl has many, many ways to do something.
Python has One True Way.
Ruby has more than one way, but some are better than others.
An oddity is that what’s better can depend on circumstances, which is why providing more than one way is better.
I think pattern matching is the bee’s knees. But it can lead to code that isn’t easily to grasp at a glance, at least for some people.
For example, I had tests that had to dissect changesets to look at subcomponents. I find assertions like this more easy to grasp:
I think it’s important to note that:
assert_fields style.I think it’s OK to offer people options and let them decide, even if they decide differently than I would.