Make Testing Style consistent

[fanminshi]

Currently, our testing codebase is mixed with different testing style and testing framework. We should have one standard on how we write tests and also which test framework to use. It will be nice to create this standard also write a testing guide for new contributors.

[lburgazzoli]

related to #309

[fanminshi]

@MalcolmSanders would you like to work on this? Your namespace pr has great tests.

[yb172]

@fanminshi @lburgazzoli regarding JUnit5 - do you know if JUnit5 adoption is going well? I've looked at the docs and while JUnit4 is plain and simple, JUnit5 has tons of things and I'm afraid it could quickly turn tests in unreadable mess of conditions, tags and filtering, parameters and so on.

The only convenient thing I could see in JUnit5 are parameterized tests. It doesn't look like we need custom test engines, assertions are covered by "AssertJ", having tests executed in order is a bad practice. And we could do parametrized tests in JUnit4 just by defining test cases in test method and using soft assertions - so technically JUnit5 could be removed from the project.

From brief search it doesn't look like JUnit5 has wide adoption. Guava, Hikari connection pool, guice, even spring - all seem to be using JUnit4. Well, ok, these all were created before JUnit5 was released but still it doesn't seem there are efforts to migrate to JUnit5.

Do you know something about it? And what do you think: better to put up with complexity and move to JUnit5 or stay simple and just use JUnit4?

[lburgazzoli]

My experience with junit 5 is in 99% of the case the same as using junit 4 and migration was in most of the case a simple change on the import directive plus some few minor things.

The reason of junit 5 exists is because of junit 4 limitations so I would at least give a try and see how complex it is and in any case we can use the junit 5 classic module to run "classic" junit 4 tests.

So I don't think migrating to junit 5 means adding complexity and in most of the cases the complexity is because tests are poorly written (i.e. abusing of @dependsOn with test written that were written with TestNG)

[fanminshi]

@yb172 I'd suggest we just try junit 5 like @lburgazzoli suggested to get a feel how it is.

[yb172]

@fanminshi Yes, on it: #545. So far looks ok, parameterized tests are much nicer. Still figuring out what would be the best way to move EtcdClusterResource to extension.

[yb172]

Related to #550

[github-actions]

This issue is stale because it has been open 60 days with no activity.
Remove stale label or comment or this will be closed in 7 days.