About unit testing and UI standardization to simplify UI scaffolding code

[shlxue]

A JUnit 5.x extension for hop plugins: https://github.com/shlxue/hop-tools

In the past month, we have been using our free time to migrate 100+ kettle plugins.

This is a very arduous task. It is not about upgrading these plugins itself, but about how to better integrate hop with our existing application system. We are still trying

We have a sample testing module for kettle plugins: pdi-plugin-testing for plugin functional testing.
But with the introduction of beam engine in hop, we are considering whether we need to refactor the implementation here

Now：
the junit extension: only a test template is implemented to detect whether the plugin dialog is standardized

If possible, I would like to add the testing module to hop repository

[shlxue]

@mattcasters @hansva @bamaer

[dmainou]

How does this differs/is better than the current implementation of unit tests?
https://hop.apache.org/manual/latest/pipeline/pipeline-unit-testing.html

[hansva]

Hi @shlxue ,
I've been on a break. I skimmed through what you are doing and it looks great!
I'll try to take a look in more detail as soon as possible

[mattcasters]

This is very interesting Shl Xue. Could you tell us more about your concerns regarding the Beam pipeline engines?

[shlxue]

Reason: Unit test coverage of the code. The test report can provide a more direct indication of the resolution of the problem

Our customers often need to provide verification results for each upgrade change to confirm that the problem can be truly solved. Generally, the corresponding verification results are provided through unit testing or manual testing and verification by testers.

There are too many problems with manual testing or simply executing some hpl pipelines:

• The testing process is often a black box
• Differences in understanding of the problem can also lead to inaccurate results
• Takes up too much labor cost

In contrast, we want to use unit test coverage as a validation result. It is more accurate.

For different pipeline engines, we want all hpl pipelines to work properly and have the same output. However, this may not be the case: some hop plugins often introduce some heavy and relatively heavy framework dependencies due to the needs of the runtime environment, such as the incorrect version of some commonly used libraries, which may lead to errors in the running results; Some cases can be performed normally, but may be inaccurate due to various reasons.

In our application, we need to collect the execution results and performance data of all plug-ins to locate the cause of the problem when there is a problem.

So for code, unit test coverage is a very important report. This report is required for code reviews prior to going live to production.