Closed timothypratley closed 5 years ago
Hmm, yeah I think this is just something cljs.test
does I'm afraid, maybe someone who's dealt with this before has a better trick but I'll sometimes wrap the failing code in a (try (catch ...))
that logs out the entire error. You could even wrap that up in a macro or function to make it a little easier to write.
If you want nice formatting of your spec errors, I'd suggest using expound to do your checking. You can use it alongside orchestra to get full instrumentation with human readable errors! It works really well, kind of Elm inspired? I love using it at network boundaries personally.
I hope this helps at least a little bit! Even if it's not exactly what you were hoping for. I hope you're having a great weekend :smile:
Thinking about it, I would imagine it's the cljs.test/is
macro that's swallowing these, maybe there's some config in there like something you can bind or you could write your own is
that catches and displays errors properly?
Good ideas, thank you!
Hi, thank you for the fantastic library, this is very useful!
This isn't really an issue so much as a question, sorry I wasn't sure where to ask. Please feel free to close this issue immediately.
When I get an exception inside a test, it gets swallowed like so:
The easy workaround is I put the code outside a test and run it again to get info on where the problem occurred.
Conversely, sometimes I get exceptions thrown from spec that would really benefit from some interpretation. Is there a way for me to include figwheel style error formatting in my command-line test command?