Scannable map or struct assertions

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:

Screen Shot 2019-12-23 at 5.54.30 PM1132×312 47 KB

I think it’s important to note that:

1. people who prefer a pattern-matching style can still use it.
2. those people can easily understand assert_fields style.

I think it’s OK to offer people options and let them decide, even if they decide differently than I would.

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.

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.

@devonestes It’s true that the output of assert_fields doesn’t get the coloring, so you can see this:

Screen Shot 2019-12-23 at 5.21.21 PM770×134 15.8 KB

I’ve thought of hooking into the differencing machinery, but honestly what I’d do is add an assert:

Screen Shot 2019-12-23 at 5.25.10 PM968×102 14.6 KB

and type ^C-,-a in Emacs to rerun the single test and see:

Screen Shot 2019-12-23 at 5.25.32 PM796×138 20 KB

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.)

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.

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.

What about an assert_match, with guards and all, it would handle that case fine.

I’m conflicted here, it’s the assert_copy I don’t get at all. Even the name is confusing me.

Given that this function only returns an approximation (We don’t account for time in our assertion) for a given input.

Maybe this just boils down to the unfamilirity of a strongly type language and how variable assignments works.

This has completely different meaning as:

map = %{
  name: "Bossy",
  tags: &Enum.empty/1
}

assert %{
    name: "Bossy",
    tags: &Enum.empty/1
  } = map

Would fail. This would be irritating even more, at least for me.

I like simplicity of current mappings and the fact that these allows me to compose them easily. I never had problems with remembering that few assignments left.

However as @devonestes said, the assert_copy seems interesting though.

assertions isn’t intended to be general purpose - I’m hoping for it to just include everything that is commonly used. Changeset & Repo based assertions are something I’ve been meaning to add for a while, but I haven’t yet been able to come up with an API for those that I like. If you have some ideas for that, definitely open up an issue and we can discuss it there!

I don’t think I’d accept assert_fields since it is an exact copy of asserting on a match but without the really helpful error message (including the colored diff of match failures). I would say that your assert_copy is equivilant to assert_maps_equal or assert_structs_equal, but I like the addition of an except option, since that exact thing would be kind of difficult to do at the moment if you had a map with 30 keys and you wanted to make sure 29 of them are equal, you’d need to list all 29 keys instead of just listing the one that should be allowed to be different.

For the predicates, I made it so all of the functions like assert_maps_equal were composable, so you can do just about anything you like in there. But, for your specific case where you’re asserting on an empty list, I’d prefer to match on the empty list both for clarity (in my book that’s more clear) and also for performance.