-
-
Notifications
You must be signed in to change notification settings - Fork 210
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
rewrite :readme-examples from spek to junit5 #1681
Comments
Hello @robstoll, can I work on this?
I'm thinking to try this literally in first. |
@hubtanaka sure go for it. Now that you are part of the core contributors, you can assign an issue to yourself by your own 🙂 I don't know if one can turn a failing test into a successful one with a TestExecutionListener. So that's something to figure out. |
Since last Monday, my daytime job has suddenly become busy💤 I'll read some recent commits related to Spek. |
As conclusion of this weekend, TestExecutionListener seems not to be able to change test results for me. What I did
So I did not find a simple way to handle failing test with I'm thinking to find another way to solve this. |
I'm reading https://junit.org/junit5/docs/current/user-guide/ |
I suppose an InvocationInterceptor could do the job (did not try it out tough) |
@robstoll thanks for your information! |
You are right. It worked 💯 I wrote two simple test classes and two extensions which override InvocationInterceptor. ex1) ex2) So as next step, I'll try to implement an InvocationInterceptor which has handleSuccsess and handleFailure like ReadmeExecutionListener. |
I would like to write an interim report. What I did
This issue has become a long journey a little bit, but I think I'll be able to create a PR in a few more days. |
@hubtanaka first of all, don't stress yourself, totally fine if it takes longer, regardless of the reason. Maybe it is harder/trickier than expected, you have other work to do or just because it is nice outside and you want enjoy the good weather. Your contribution is very much appreciated regardless the time it needs 🙂 I'll probably have time to take a look at your branch next week ps: Since spek is not well supported by intellij (by now). Following a hint, how you can run a single spec (might come in handy to debug a problem). Since the spec is under src/main intellij doesn't provide a run gutter or run in the context menu. Annotate the spec with org.junit.platform.commons.annotation.Testable. Following an example: |
@robstoll thank you for your kindness and information. I'll try your spek test tech later. it seems useful. |
Finally had time to look at your branch. The problem you see with the deletion comes from two things:
=> due to this the folder is already there once you call PathSpec a second time. A simple workaround is to move the deletion into the method:
However, this only hides that the root cause is the custom engine (and would include the workaround in the readme). I suggest we don't follow the custom engine approach as it brings several problems:
So I took a look at InvocationInterceptor again and came up with a solution which is still a bit a hack but works better overall as it uses Jupiter and no custom Engine: #1834 |
Thanks for your hard work.
I agree. To be honest, I felt my custom engine approach was overkill for our purpose. I'll review your PR (and I'd like to learn how to use InvocationInterceptor) |
Platform (all, jvm, js): all
Extension (none, kotlin 1.3): none
Code related feature
the readme-example project executes tests and write the output of the failure into the README.md of Atrium. It is based on Spek and since Spek doesn't advance, has bugs which makes it impossible for Atrium to upgrade respectively, we should move away from spek entirely. This includes also the readme-example project. Instead of providing an own TestEngine (which uses SpekTestEngine) we should write just normal tests and use a TestExecutionListener or similar (something which is able to turn a failing test into a successful one and vice versa) to achieve the same.
This isn't a good first issue but might be fun to tackle. In the end, executing ./gradlew :readme-example:build should generate the same output in README.md (see for instance
<ex-first>
in README.md and the corresponding FirstExampleSpecOnce we don't rely on spek, we can also update junit #1677
The text was updated successfully, but these errors were encountered: