Scannable map or struct assertions

Interesting! I actually have a library that I think would suit this case for you (and hopefully provide really great error messages for you as well). Check it out here: assertions | Hex

Is there something in your functions that you can’t easily do with that library? If so, I’d love to add it there. I envision that library as (eventually) a big collection of common assertion abstractions like these ones you mention.

I hope you are aware that you can leverage pattern matching here, so you could simply do all of this in one line.

assert %Animal{name: "New Bossie", lock_version: 2} = AnimalT.update_for_success(original.id, params)

I find it easier to read something like that:

assert %{
    name: "New Bossie",
    lock_version: 2
  } = AnimalT.update_for_success(original.id, params)

This also makes “predicates” simpler:

assert %{
    name: "Bossy",
    tags: tags
  } = bossify("Bossy")
assert Enum.empty?(tags)

I use your library, but I didn’t see functions that did the same things. Did I miss something?

I was planning to ask you if you’d accept these functions into your library, so YES to “I’d love to add it there”. How do you feel about chaining assertions (from Chained assertions)? With the exception of things like assert_raise, the return value from an assert_* is meaningless, so it does no harm to provide return values that allow chaining.

I also have a set of Changeset-oriented assertions. I don’t know how they’d fit into a general-purpose library.

Yes. My bias as a person raised in a language culture that reads left-to-right, and so thinks of time as flowing from left to right or top to bottom is that it’s better to put the code that produces the value-to-be-tested before the code that checks that value.

In my Clojure testing library, I illustrated that with book examples

I wouldn’t force that bias on anyone, but for those that share it, this code might be nice.

Because I have an unusually bad short-term memory for a programmer, I prefer not to introduce a token (like tags) that I have to remember as I scan from the point of definition to the point of use:

assert %{
    name: "Bossy",
    tags: tags
  } = bossify("Bossy")
assert Enum.empty?(tags)

I’d rather combine the two:

assert %{
    name: "Bossy",
    tags: &Enum.empty?/1
  } = bossify("Bossy")

… or use my preferred notation, which puts the cause visually before the effect (given that one reads in English order).

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.

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.

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.

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