-
Notifications
You must be signed in to change notification settings - Fork 14
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
Short circuit on failed assertion #21
Comments
Fixes nubank#21 The `assert` macro receives a body and, if this body doesn't return a truthy value, it will throw an exception with the details to short circuit the flow.
Fixes nubank#21 The `assert` macro receives a body and, if this body doesn't return a truthy value, it will throw an exception with the details to short circuit the flow.
A way to check for failed runs that I think is interesting is used in kaocha through clojure test's report counters: https://github.com/lambdaisland/kaocha/blob/master/src/kaocha/type.clj |
One thing to keep in mind: |
I don't see a strong reason to short circuit. I actually see reasons for not short circuiting. Supposing you do an action that has several consequences, than you make several assertions for each of the consequences. These assertions are independent and it is meaningful to know which of them passed or failed. If the flow didn't fail catastrophically (with an exception) it probably should continue. The spice must flow. But I'm all open for having this behavior configurable. And also decoupling state-flow from test assertions |
I agree with the multiple assertion, but not steps. If an assertion fails between two steps, the step didn't work as expected and imo it doesn't make sense to keep running the next steps (assuming a flow is exactly for actions that depend on the effect of previous actions) |
To the runner, flows, steps, assertions, etc, are all the same thing, so there is no way to differentiate between a step and an assertion. Also, since you can arbitrarily nest flows inside assertions inside flows, there is really no way to identify when "an assertion fails between two steps" I think the simplest thing is to either short circuit on error or not (configurable - default TBD), and runtime exceptions should be treated the same as failed assertions. |
Hey, so the |
I would expect a failed assertion (i.e.: failed
verify
ormatch?
) would short circuit a flow. This is not the case and as of now we don't have an easy way of asserting that it happened when running a flow.The text was updated successfully, but these errors were encountered: