Open michaelbeaumont opened 6 months ago
hey @michaelbeaumont there actually isn’t anything that supports this formally. when faced with situations like this I usually write a quick helper to pluck the fields for me or construct an array of matchers. In fact, I often end up with a mini-DSL tailored to the domain when I’m testing some complex behavior. For example:
Expect(PluckFoo(actual)).To(HaveExactElements(PluckFoo(expected))
With that said, I could imagine adding generic functional helpers like that to Gomega (or perhaps a subpackage of Gomega) that could implement the basic elements of Map
, Pluck,
Find`, etc. that play well with the Gomega ecosystem of matchers.
(I should add - there are probably functional-esque libraries out there that do this well. are you familiar with any?)
I'm coming too across such situation from time to time, so I would be interested too.
something along this here: https://github.com/repeale/fp-go/blob/main/map.go? Albeit not returning the fn, but the final outcome...?
yep something like that.
Probably I'm missing something obvious from the docs but say I have two slices of structs that I want to compare but only on one field.
I want to write something like:
But the values in
Fields
have to be already instantiated matchers. But what do I callEqual(??)
with?or something like
I can see that
HaveExactElements
dynamically creates its defaultEqual()
matcher from the expected elements but it wants a given custom matcher to already exist.This is ultimately so painful because it's so painful to map values in go but it feels like this is something Gomega is in a good position to solve.