Been thinking of ways that assert_values_for doesn't quite reduce effort and one of the more common places is when the two map-likes (map, struct, ecto schema) have different names for the fields, but the data is the same. An example might be when a database struct, Thing, has an id field, but a system event might call it something like thing_id.
As with the list assertions, I think the biggest challenge is the api/dsl to make it clear to someone unfamiliar with the library what is going on.
The fields list will need to be the source for the starting key. But then, is it assumed that the fields passed to fields are always a match to the fields on expected? If so, I think we could possibly get away with a less verbose, more implicit dsl, but I'm not sure that that is always the case. If not, we should be more explicit.
Here is a sketch of what it could look like. I would love feedback or ideas that aren't presented here at all.
assert_values_for(
expected: quote_request,
actual: quote,
fields: fields_for(OmniWeb.Schema.QuoteRequest),
field_name_translations: [
# explicit
origin_postal_code: [actual: :origin_zip],
destination_postal_code: [expected: :destination_zip, actual: :destination_zipcode],
# implicit
pieces: :freight_pieces, # assumes field is from expected and that this is on actual?
weight: :freight_weight
],
skip_fields: [
:selected_common_pickup_accessorials
]
)
Been thinking of ways that assert_values_for doesn't quite reduce effort and one of the more common places is when the two map-likes (map, struct, ecto schema) have different names for the fields, but the data is the same. An example might be when a database struct, Thing, has an
idfield, but a system event might call it something likething_id.As with the list assertions, I think the biggest challenge is the api/dsl to make it clear to someone unfamiliar with the library what is going on.
The
fieldslist will need to be the source for the starting key. But then, is it assumed that the fields passed tofieldsare always a match to the fields onexpected? If so, I think we could possibly get away with a less verbose, more implicit dsl, but I'm not sure that that is always the case. If not, we should be more explicit.Here is a sketch of what it could look like. I would love feedback or ideas that aren't presented here at all.