Am I the only one who can't spot the difference in map keys

Something to do with the refunded_at key? One is nil, the other gets a value from somewhere.

both clauses expect a :amount key that is not present in the map that is passed as argument.

edit: not sure if your question is about the error or a better way to format this.
in the way you’re using it, it would be better to have a struct or at least use the dot notation to extract the values instead of pattern matching them on function clause:

def build(something) do
  created_at = something.created_at
  ...
end

@cevado I mean better formatting. I updated the op mentioning this.

Pattern-matching on huge maps is, IMO, hard to read in code - and correspondingly harder to read in test failures.

For instance, the error message you posted suggests there are two build heads:

def build(%{
  created_at: created_at,
  refunded_at: nil,
  id: job_id,
  provider_id: provider_id,
  sale_id: sale_id,
  customer_id: customer_id,
  appointment_id: appointment_id,
  amount: total_gross,
  type: fee_type,
  currency_code: currency_code
}) do
...
end

def build(%{
  created_at: created_at,
  refunded_at: refunded_at,
  id: job_id,
  provider_id: provider_id,
  sale_id: sale_id,
  customer_id: customer_id,
  appointment_id: appointment_id,
  amount: total_gross,
  type: fee_type,
  currency_code: currency_code
}) do
...t=
end

Sharp-eyed readers may spot that refunded_at is matched to nil in one and bound to refunded_at in the other, but it’s the same kind of difficulty you’re highlighting with the test failure message.

+1 for @cevado’s suggestion - writing this as:

def build(args) do
  total_gross = args.amount
  ...
end

would make the test in your original post fail with a KeyError complaining explicitly about amount not being present in args.

This is just one example and it’s not only pattern matching related. In tests or dialyzer errors the comparison is between 2 maps that are very similar and you may get it randomly because something started to fail. This was always causing issues for me and I wanted to raise it. I’m happy to implement it when we have a good idea how to handle this.

this specific formatting only happens on function clause errors, i don’t think it can be better formatted.
for tests if you’re using ExUnit it shows only the diff with it highlighted if you’re asserting a pattern match. my suggestion in that case is to do something like:

expected_response = %{...}
...
{:ok, response} = function_testing(...)

assert expected_response = response

We have a big elixir codebase and sometimes the expected response is 100 lines long. I know it shouldn’t be like that but it is how it is.

At this point I’d suggest refactoring assertions to work on smaller subsets instead of comparing the whole response at once:

assert {:ok, response} = function_testing(…)

assert something == response.a
assert something_else == response.b
assert something_else_again == response.c

I need to try how a llm will handle the refactor, otherwise it may take a lifetime

Having not used LLMs myself, if that doesn’t work you might have some luck with Sourceror depending on how consistent your map assertions are.