unit-test-exchange-maven-plugin

This plugin works as a tool to convert unit tests from one standard to another. The goal is to support conversion between many types of unit tests.
Although the goal is to having it working flawlessly, it is actually, very hard to do it in practice. Think of this project as a helper if you want to convert between unit test, assertions and mock frameworks.
This project will, however suffer multiple improvements as I go along, and so your input is very valuable and please feel free to open issues if you find bugs. I’m constantly trying to fix bugs I find and if I have yours, I can make this project event better for all of us.

Release Dates

— Stand By —

There are no official dates planned yet. The code is still very experimental and there are no snapshots yet. You can, however, checkout the code already, compile it, and run it locally against your unit tests. The maven-plugin is not ready yet, but you can already try the runner. Check the Readme.md file on how to use it. I don’t offer any guarantees at this point though, so make sure to check the results before committing anything. Checkout the Roadmap for more detais.

Options

Option	Function	Source Code	Target Code	Status	Manuals
1	Converts from JUnit, Mockito, Hamcrest, AssertJ, Wiremock Rules to MockK, Jupiter, Wiremock for Jupiter and Kotest assertions	Kotlin	Kotlin	InDevelopment (Mostly working. Wiremock not available yet. Still buggy in some Mockito corner cases)	Option 1 Manual
2	Converts from JUnit, Mockito, Hamcrest, AssertJ to MockK, Jupiter and Kotest assertions	Java	Kotlin	On Hold	N/A

Before running this plugin

Make sure you have your code formatted according initial expectations as much as possible. The rules are:

Annotated methods in separate lines
Annotated test methods should have no space between parenthesis if they receive value directly as the following example:

@Test(expected = IOException::class)
fun testThisStuff() {
}

Make sure that the source code and target code match the choice you make
Clean imports and make sure you removed all code not being used.
Remember to always have a space after a comma. This is usually standard, and you don’t have to think about this.

Assert.assertThat(text, Matchers.containsString(test))

Take special note on manually hard-coded error messages. This converter does not keep the error messages in most cases. Frameworks like Kotest already describe with enough depth what happens to a test when it fails. I will, however provide support for this in the future. (see table above)
There are no 100% guarantees that the resulting code will compile and run immediately after you run this. Manual intervention afterwards may be necessary.
Always check your code before committing. Check your SCM(GIT/SVN) for code errors. Compare the local version with the latest commit before making a new commit
If there are compiling errors, make sure to fix them. If there are running errors make sure to fix that as well.

FAQ

Why did you built this in a hardcoded way? Wouldn’t it be better to have a configuration file and use that with a Regex expression list?
R. Short answer to this question is because it is not useful. A Long answer is much more complicated than that. This engine is implemented with search and replace functions which make heavy usage of ReGex expression. This demands processing time and for the most part it is a very reliable process. Not very efficient, but very reliable. However, the sequence of regular expressions change the code per executed expression. Some search expressions require extra processing such as the case of migrating a shouldThrow from annotated unit tests. On the other hand I’m developing with this project a reliable way to convert unit tests to whatever version you want them to be converted. This is especially useful for companies that want to update their code, have thousands of lines written in JUnit 3 and 4 and now want to move on to other frameworks like Kotest, Jupiter 5 or even Kotest engine, just to name a few. Making this reliable is a major concern for mine in this project. This implies the implementation of unit, integration and regression tests which will test if the sequence of regular expressions and the code processing on the fly works as it is meant to be. Allowing external configurations would get in the way of achieving an increasing reliability for every release.

Buy me a coffee

I hope you enjoyed this repository. If you did, you can optionally please buy me a coffee, which supports me to constantly improve and make new free content regularly for everyone. Thank you so much!