-
Notifications
You must be signed in to change notification settings - Fork 84
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wrap executing test to match clojure.test for fixtures #368
Conversation
Codecov ReportBase: 75.26% // Head: 75.32% // Increases project coverage by
Additional details and impacted files@@ Coverage Diff @@
## main #368 +/- ##
==========================================
+ Coverage 75.26% 75.32% +0.06%
==========================================
Files 51 51
Lines 2733 2736 +3
Branches 256 256
==========================================
+ Hits 2057 2061 +4
+ Misses 515 514 -1
Partials 161 161
Flags with carried forward coverage won't be shown. Click here to find out more.
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. ☔ View full report at Codecov. |
63c6d61
to
d59cad8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hi, @NoahTheDuke, thanks for the PR! (And thank you for updating the CHANGELOG
and test!). I left one suggestion. I think I'll have another person take another look because of how central the changed code is.
the-var :kaocha.var/var | ||
meta' :kaocha.testable/meta | ||
:as testable} test-plan] | ||
(defn test-var [{test :kaocha.var/test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wonder if it would be a little clearer if test-var
itself returned a function, rather than having to wrap it later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Haha if you look at the commits, you'll see i went back and forth on that. I went with wrapping with the function at the call site instead of returning a function because 1) it matches how clojure.test does it and 2) I find it harder to reason about functions that return functions vs letting the wrapping function be part of the implantation details.
However, both are reasonable and I'm good to change it if you desire.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Those reasons make sense. The reason for returning a function is that I'm not sure you'd ever run test-var
without wrapping it.
Maybe it just needs a clearer name, like run-test-var
. I guess the test
in test-var
could already be interpreted as a verb, but it's not clear to me.
Just in case it's not clear, the change is relatively small, it just looks big because of indentation/whitespace changes. If you toggle showing whitespace, you'll see it's "merely" moving the bulk of |
Yeah, I tried using difftastic and it reduces the diff considerably. (Although even that tool doesn't point out that most of the remaining changes are really "moves"). My comment about wanting another set of eyes was more me wondering about consequences to this change I didn't think of, as this code path is hit for a large number of tests. |
Hope y'all had a nice holiday break. Is there anything I need to do to get this doubly reviewed? |
@NoahTheDuke Sorry for the delay. We've been on break this week as well. There's not anything you need to do to get that review. It might be good to have a more spelled-out process for getting review, but right now we the maintainers contact reviewers internally. Normally, a single review pass is enough; this PR is just a small change I suspect could have subtle implications. |
Cool, thanks @alysbrooks. I don't mind being patient, just want to make sure you're not actually waiting on me for something I missed. |
I'm having another look at the code, and I think this might interfere with |
By "interfere", do you mean that it would exit kaocha with an exception and stack trace instead of reporting a fail? In both cases, the test run is stopped immediately. For example, I copied the contents of my
The purpose of my change is to expose these, to not swallow exceptions in test functions. If the "swallowing exceptions" behavior something you want from Kaocha then this change isn't appropriate and I'll just have to maintain my own fork. Thanks so much for the review. |
All good then, I just wanted to make sure since fail fast internally uses exceptions. |
Ayyyyy thank you! |
Fixes #367
The fix is to wrap the existing test execution logic in an anonymous function, and use that instead of the given test function itself so that any thrown exceptions are caught by the test wrapping logic and not by an
:each
fixture.