search

openlcb / OpenLCB_Java

Java implementation of OpenLCB / LCC protocols. This implementation operates inside JMRI, and can also be used inside Android apps.
6 stars 9 forks source link

More JUnit4 conversions #134

Closed pabender closed 6 years ago

coveralls commented 6 years ago

Coverage Status

Coverage increased (+0.1%) to 69.12% when pulling 945144847d2b77cd09e3aa1e66ee4c405488cd47 on pabender:master into 0f0c887fc0b535cb1bc8a858168573d76a65e920 on openlcb:master.

balazsracz commented 6 years ago

@pabender Question: is it true that after the junit4 conversion we can get rid of the PackageTest classes that have a hand-edited list of classes to include and run? I'm also trying to understand whether I might be running every test two-three-four times.

pabender commented 6 years ago

Sent from my iPad

On Sep 27, 2018, at 3:52 PM, Balazs Racz notifications@github.com wrote: @pabender Question: is it true that after the junit4 conversion we can get rid of the PackageTest classes that have a hand-edited list of classes to include and run? I'm also trying to understand whether I might be running every test two-three-four times.

Largely yes.

Maven’s surefire plug-in ( which we are using ) will automatically grab any test class that ends in “Test”. We have it set to ignore the PackageTest files and AllTest.

There are a few “test like” things in the test tree that aren’t named with a Test file name, and those are currently triggered via test suites. Most of these suites we need to keep are not currently named as PackageTest.

If we want to maintain compatibility with ant, then I think we need to keep them around.

What I am looking forward toward is converting the tests to JUnit 5. Once the tests are all in JUnit 4 format, I should be able to automate the conversion.

It looks like we can tag tests and filter them in the JUnit 5 interface, so the tests that build an interface object, requiring thread shutdown, can be saved for CI time.