Making error messages more readable.

[stroiman]

As you know, I have this code where I am embedding a v8 engine in Go.

You've been very helpful with feedback so far, and provided ideas I didn't think about, or pointing to features I didn't know about. So I just though I'd see if you have any ideas here :)

To verify the JS binding layer, the verification involves executing JS code.

E.g., I might have something like

Expect(ctx.RunTestScript(`new CustomEvent('foo') instanceof Event`)).To(BeTrue())`

I want to make this read better. The first idea as to have more specific matches like

Expect(ctx.RunTestScript(`new CustomEvent('foo')`)).To(BeJSInstanceOf("Event"))

The matcher would need to execute JS, but that's not really an issue.

But my next thought was; use JS assertion libraries to write the assertion in JS. E.g., using 'chai', I believe the syntax is like:

Expect(ctx.JSVerify(`
expect(new CustomEvent('foo')).to.be.an('Event');
`)).To(Succeed())

This should work; JS Exceptions are transformed to Go error instances. But the error messages are probably aren't that useful.

One particular nice feature about chai is that it's extensible. And while using the extensions for the most part only makes test code slightly more readable, the error messages are almost always much more helpful. E.g., chai-dom writes the HTML of the element failing an assertion; instead of just a string or boolean mismatch.

So maybe a better solution is to in some way transform JS errors into a more readable format. I haven't looked at it, but a chai error probably have some very well defined properties, I could use.

So maybe you have a few ideas about strategies in Gomega I could use for this? Or completely alternate ideas. E.g., I'm not too keen on having a repeated Expect(...).To(Succeed()) in 80% of all the tests.

---

p.s., This probably belongs in the gomega repo, but that doesn't have a "Discussions" board.

p.p.s., I'll gladly find some examples of how chai plugins display error messages, if you want something for inspiration.

p.p.p.s., I wrote a test library in a similar style (nested describe blocks) for OCaml :) If you're curious, it's under stroiman/opam-speed. It uses features unique to the OCaml type system to deal with some problems, e.g., there is no run-time type information in OCaml, so no interface{} type and run-time type checks.

[stroiman]

Hmm, occurred to me just after writing, that for the repeated Expect(...).To(Succeed()) I could make a custom matcher, something like this

Expect("new CustomEvent('c')").To(MatchChai("be.an('Event')"))

Which I could wrap in some helpers

ChaiExpect("new CustomEvent(...)").To("be.an.('Event')")

Which I think maybe isn't to bad an interface ...

If I use chai, I think that making that explicit in the Go test is very sensible.

[onsi]

Hey @stroiman - yes you got it! I'm a fan of building out domain-specific custom matchers and leveraging Chai makes a ton of sense here. I would recommend going with the MatchChai approach as it will give you a matcher that will compose well with the rest of the Gomega ecosystem (e.g. you can use Eventually and Consistently and you can combine it with other matchers like And(MatchChai(..), MatchChai(...))).

The alternative would be to build out a suite of custom matchers a la BeJSInstanceOf() - but I suspect leveraging the chai ecosystem could help you go faster in the long run. One awkward thing in a case like this is the sense that the tests live in two different worlds - some are pure Go, some are Go + JS with a fairly heavy dose of JS (pulling chai in will make it feel like a heavy dose of JS) and you can end up with lots of different ways of testing things ("do I use chai here? or should I just get a return value and make an assertion in Go?"). I'd offer that's all OK and you should just keep playing with it to see what gives you the most natural and expressive way to get the kind of test coverage you need to feel confident in the code.

[stroiman]

Hey, thanks for the feedback - once again :)

Good point with the possibility to compose matchers, I'll keep that in mind.