Skip to content
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

Fix assumption errors #1645

Draft
wants to merge 30 commits into
base: master
Choose a base branch
from

Conversation

l-1squared
Copy link
Collaborator

@l-1squared l-1squared commented Jun 5, 2024

…ests

TODO:
[ ] update statistics to also account for for aborted scenarios
[ ] html app recognizes aborted scenarios
[ ] html links aborted scenarios
[x] asciidocs links aborted scenarios
[x] plain text recognizes aborted scenarios
[x] example tests with aborted scenarios

@l-1squared l-1squared changed the title chore(Test framework): switch to using junit5 by default for jgiven-t… Fix assumption errors Jun 5, 2024
@l-1squared l-1squared force-pushed the fix/Issue-1625-thorough-assumption-handling branch from c25ed73 to a689199 Compare June 6, 2024 05:29
@l-1squared l-1squared force-pushed the fix/Issue-1625-thorough-assumption-handling branch from 86c00fc to a8a259a Compare June 17, 2024 13:58
@l-1squared l-1squared force-pushed the fix/Issue-1625-thorough-assumption-handling branch from 2e62da5 to e9aeb93 Compare August 5, 2024 14:18
The JUnit 5 Executor uses a thread global scenario holder to handle its scenarios. For some reason that gets called when executing the JUnit 4 tests.

Maybe its a runner issue?

Signed-off-by: l-1squared <[email protected]>
junit4 tests in junit5 come with a filter that gets passed to the test execution listeners. Unfortunately they make the result provider record wrong values

Signed-off-by: l-1squared <[email protected]>
assertJ checks what kind of frameworks are on the classpath (with a preference for testng) and chooses the exception that framework would throw.
Therefore, there is no need to test specifically for assertJ assumptions.

Signed-off-by: l-1squared <[email protected]>
probably not the right solution

Signed-off-by: l-1squared <[email protected]>
to easier read what these tests actually print.
-> consider reverting to noop logger to avoid spamming the log

Signed-off-by: l-1squared <[email protected]>
That produces so many problems, its worth its own PR

Signed-off-by: l-1squared <[email protected]>
TODO:
* TestNg and JUnit completely ignore all steps taken when an assumption fails, which is WRONG.
* Junit tests interfere with each other
* TestNg and JUnit completely ignore all steps taken when an assumption fails, which is WRONG.

Signed-off-by: l-1squared <[email protected]>
current state is that a failed assumption is flat out ignored by the report, which is not desireable either

Signed-off-by: l-1squared <[email protected]>
adapt unit tests

Signed-off-by: l-1squared <[email protected]>
@l-1squared l-1squared force-pushed the fix/Issue-1625-thorough-assumption-handling branch from e5b49e9 to 00ba4da Compare August 9, 2024 10:30
@l-1squared l-1squared force-pushed the fix/Issue-1625-thorough-assumption-handling branch from 00ba4da to 15e42bf Compare August 9, 2024 10:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

JUnit5: failed assumptions are handled like failed test cases in JGiven reports
1 participant