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.

Sign up for GitHub

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

Jump to bottom

Migrate to JUnit5 #1186

Closed
1 of 2 tasks
abelsromero opened this issue Apr 22, 2023 · 2 comments · Fixed by #1192
Closed
1 of 2 tasks

Migrate to JUnit5 #1186

abelsromero opened this issue Apr 22, 2023 · 2 comments · Fixed by #1192
Labels
infrastructure
Milestone
3.0.0

Comments

@abelsromero
Copy link
Member

abelsromero commented Apr 22, 2023 •
edited
Loading

Trying to bump JUnit to v4 to JUnimake use of newer features I am finding road-blockers.

Normal JUnit4 and some Spock tests can make use of the vintage compatibility library, but those with Spock and Arquillian can't.
I see Arquillians hasn't made a proper release in a long time, and the latest Spock integration (arquillian-spock-core) is 1.0.0.CR1 from Sept 2019, and is not compatible with newer Spock versions.

Is there any reason no to start rewriting tests to remove Arquillian dependency? I am thinking of re-writing the features as a JUnit5 extension that should work.

I am planning to do this in 2 PRs:

  • Set Junit5 as default engine
  • Reimplement Arquillian features (Asciidoctor and ClasspathResource injection) as Junit 5 (anything else?), and rewrite tests We could keep at the end, see Replace JUnit4 by JUnit5 #1192
@abelsromero abelsromero mentioned this issue Apr 22, 2023
Merged
5 tasks
@robertpanzer
Copy link
Member

Good idea!
I also think that it would be good to "slim" down our dependencies.
Although I hate to say it I would be fine with dropping Arquillian.

The only reason should be the amount of work :)
But if we can migrate gradually then I think the task would be far less intimidating.

@abelsromero
Copy link
Member Author

abelsromero commented Apr 23, 2023 •
edited
Loading

Although I hate to say it I would be fine with dropping Arquillian.

Me too, it's not only part of the project but of the contributors. But in the end, even if we could keep it using the RC versions, using a JUnit extension means fewer dependencies and a framework more supported. And it's easier for contributors too. I see really no advantages in Arquillian.
So far I have been able to remove Arquillian from some tests adding a few lines to init Asciidoctor and the classpath tools.
That's the part we can refactor to reduce boilerplate, but it's not a big complexity.

But if we can migrate gradually then I think the task would be far less intimidating.

The current PR aims for that, but there's the issue of Spock compatibility, newer versions have removed org.spockframework.runtime.Sputnik which org.jboss.arquillian.spock.ArquillianSputnik uses, so I've been forced to remove Arquillian wherever we had @RunWith(ArquillianSputnik) 😞 .
That's maybe the biggest re-write so far.

PS: btw, org.junit-pioneer:junit-pioneer does not pull any third-party lib which is nice.

@abelsromero abelsromero added this to the 3.0.0 milestone Apr 23, 2023
@abelsromero abelsromero mentioned this issue Apr 29, 2023
Merged
5 tasks
abelsromero added a commit to abelsromero/asciidoctorj that referenced this issue Apr 29, 2023
@abelsromero
Replace Junit4 by Junit5 whenissue-1186-remove-junit4
56f6e36 
* Implement new Junit5 extensions:
   @AsciidoctorInstance & @ClasspathResource annotations
   available to inject Asciidoctor instances and resources into tests.
* Update all modules to use JUnit5 and the new extensions
  'asciidoctorj-wildfly-integration-test' remains on JUnit4 for
  Arquillian compatibility.
Other changes:
* Remove some uses of deprecated APIs
* Fix typo in sample doc
* Replace use of IOUtils.readFull(File) by Files.readString(Path)
  where possible to remove third-party dependencies.

Closes asciidoctor#1186
abelsromero added a commit to abelsromero/asciidoctorj that referenced this issue Apr 29, 2023
@abelsromero
Replace Junit4 by Junit5 whenissue-1186-remove-junit4
0c51f2a 
* Implement new Junit5 extensions:
   @AsciidoctorInstance & @ClasspathResource annotations
   available to inject Asciidoctor instances and resources into tests.
* Update all modules to use JUnit5 and the new extensions
  'asciidoctorj-wildfly-integration-test' remains on JUnit4 for
  Arquillian compatibility.
Other changes:
* Remove some uses of deprecated APIs
* Fix typo in sample doc
* Replace use of IOUtils.readFull(File) by Files.readString(Path)
  where possible to remove third-party dependencies.

Closes asciidoctor#1186
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
infrastructure
Projects
None yet
Milestone
3.0.0
Development

Successfully merging a pull request may close this issue.

Replace JUnit4 by JUnit5 abelsromero/asciidoctorj
2 participants
@robertpanzer @abelsromero