-
Notifications
You must be signed in to change notification settings - Fork 52
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
feat: The invocation of a non-existing function returns null #692
Conversation
If a function is invoked with wrong parameter, the invocation should return null (instead of failing the evaluation).
A function invocation returns null if the function is invoked with wrong parameters, or no function exists with this name.
Change the name of some test cases to bring the focus on the invocation of functions.
Add new test cases for a function invocation that return null.
If a function invocation returns null, we want to verify that a failure is reported. A user of the API can access the evaluation failures to understand why an evaluation returned null. So, we should verify the reported failures. To verify the failures, we need a new base test class that returns the whole evaluation result, instead of only the return value. Create a new test matcher to increase the readability of the tests and better failure messages.
Migrate the test class from FeelIntegrationTest to FeelEngineTest. The new base test class allows using the EvaluationResultMatchers that can check for reported failures and produces better failure messages.
Replace the internal test methods by using FeelEngineTest and EvaluationResultMatchers.
Align the failure message if no function was found.
Move test case from SuppressedFailuresTest to InterpreterFunctionTest that bundles all function related test cases. Remove test cases from SuppressedFailuresTest that are already covered in InterpreterFunctionTest.
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.
LGTM 🚀
💭 We must remember to refactor the other test cases to the new standard
💭 Is there any docs to update ?
import org.camunda.feel.api.{EvaluationFailure, EvaluationFailureType, EvaluationResult, FailedEvaluationResult, SuccessfulEvaluationResult} | ||
import org.scalatest.matchers.{MatchResult, Matcher} | ||
|
||
trait EvaluationResultMatchers { |
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 like it so much, made test cases way more readable 💪
@nicpuppa thank you for your fast review. 🍰
Yes. Let's migrate the other tests step-by-step when we're touching them. 🚀
No. But I will add more details about the handling of |
Description
null
.Related issues
closes #670