-
Notifications
You must be signed in to change notification settings - Fork 98
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
Brainstorming: How to handle consecutive steps scenario #166
Comments
A simple solution would be to add an index to the rows and add a custom error message to your assertion message. Then at least you should be able to correlate the error with the row. |
Oh yes, you are right :) |
Interesting, adding "numberedRows"=true throws an exception in my case:
This is probably related to my Object[][]? |
Oh. That can be regarded as a defect :-( |
I've encountered another issue: I'm using assertions that are not thrown and cannot be intercepted properly in the loop. My idea then is to set a flag on the Object[][](just add another column), but it seems that changes on the object that are done in the method itself are not reflected when the object is formatted. Is this a technical limitation for some reason? |
That is a limitation, because the table is copied internally when the step is executed. I think this is not possible to change. |
Oh, what a pity. Then I have to check how to catch the assertions properly. |
A possible solution would be that you print the whole table again when an assertion fails. Then you can mark the corresponding line. |
One more question related to that topic: in a test step, I sometimes call further test steps that also could be invoked directly via given(), when(), then(). Is my assumption correct that in these cases, exceptions are not thrown, but the interceptor instead stops the execution directly? |
There should actually be no difference how you invoke the steps. In any case the exception is first captured by the interceptor, then the following steps are executed in a special skip mode and at the end the captured exception is thrown. |
Let me explain my issue with more details: In addition to the intial post:
This is the original approach that does not work. Checking more closely:
This method is actually only a wrapper for a technical test. The method is also directly usable in a technical then step.
The assertThat failure is not thrown, but intercepted as explained by you. When I directly replace the technical matcher with the assert, it works as expected:
In collection handling checks, this also causes issues when I want to catch/collect failures from another step method. So at least for me the default approach of intercepting all exceptions is not in some corner cases. Maybe some mechanism to tell the interceptor to further throw an exception instead of intercepting it can be introduced. Maybe some global flag can be applied to pass exceptions when I'm in a batch mode? E.g. something like
|
I have to check the code, but as far as I know, exceptions should only be captured on the outer calls of step methods and not on the inner ones. If this is not the case, this can be easily fixed. Which also would totally make sense. |
Hi Jan,
currently, I'm trying to create a table based scenario that depends on consecutive steps:
When everything is fine and no errors are raised, I can create the following output:
This is a much better approach than to create a when/then for every case as the scenario grows pretty fast as soon as one additional case is added.
But of course, this way, an error case cannot be displayed in the table itself. To do that, I'd have to be able to catch errors, mark the row where an error occurs and then throw a global error afterwards.
An error case currently looks like this
It is still readable, But only when the assert fails on a unique sequence so I can tell from which row the error is raised without debugging.
Any idea? :)
Best regards,
Niko
The text was updated successfully, but these errors were encountered: