allow nested keyword lists for `:skip_fields`

[idlehands]

It would be great to be able to annotate why certain fields are being skipped. I think the easiest way to do this is code would to be able to do something like:

assert_values_for(
  expected: user_params,
  actual: user_from_db,
  fields: fields_for(User),
  skip_fields: [
    db_generated_values: [
      :id,
      :inserted_at,
      :updated_at
    ],
    keys_different_from_params: [
      :phone_number,
      :some_random_thing
    ]
  ]
)

This is doable with minimal changes, I think (flatten and take the values?) and will allow the calls to read as better documentation and may even highlight to the coder which keys should be intentionally tested after.

[GeoffreyPS]

I have a few questions that might help define this feature further, or get at what is really useful:

Do we want to extend this feature to the :fields key?

Is there value in using this behavior for that one as well?

Do we need these to be keyword lists or is it a nested list with underscored variable names sufficient?

For example, with only allowing:skip_fields as a list of lists (instead of a Keyword) and flat-mapping in the implementation, we could end up with something like this:

assert_values_for(
  expected: user_params,
  actual: user_from_db,
  fields: fields_for(User),
  skip_fields: [
    _db_generated_values = [
      :id,
      :inserted_at,
      :updated_at
    ],
    _keys_different_from_params = [
      :phone_number,
      :some_random_thing
    ]
  ]
)

Do you see the keyword variant having further meaning? Or is it important that the sublists of fields must be named?

It doesn't seem like it's more difficult to do one implementation over the other, I do want to explore what either approach affords.

[idlehands]

Syntactically, I prefer my proposal. I recognize that the keys are throw away, which could be weird, but I would rather that than have it so that people could pass a list of lists without annotations.

[idlehands]

Is there something specific that you're trying to address here?

[GeoffreyPS]

I think the initial syntax you put forward is more a e s t h e t i c, and my questions were more to probe than anything else.

I do wonder what else we could do with the keys we would (otherwise) throw away. Are there places where this information could be useful in test output?

For example, let's say one of the keyword lists' contents gets programmatically generated (ala fields_for/1, Map.split/2, Enum.split_with/2, or similar).

assert_values_for(
  expected: user_params,
  actual: user_from_db,
  fields: fields_for(User),
  skip_fields: [
    db_generated_values: [
      :id,
      :inserted_at,
      :updated_at
    ],
    keys_different_from_params: []
  ]
)

Does an empty-list value for one of these keys result in:

• an error
• a warning
• silent tolerance

[idlehands]

Ah, great call out. I honestly hadn't thought that far. You're right though. I think that it's highly unlike that someone would intentionally add an empty list (is there a valid use case for that?) and so it would only happen if something is erroneously generated. At that point, we are doing a service to raise an error.