Reduce build duration by lowering Mockito usage

[jkronegg]

🤔 What's the problem you've observed?

Mockito has a impact on the unit test execution time (seen using IntelliJ Profiler flame graph):

project	test duration [s]	mockito contribution
cucumber-junit	4.4	31% = 1.3 s
cucumber-core	7.5	10% = 0.7 s
cucumber-java	2.8	24% = 0.6 s
cucumber-java8	1.8	27% = 0.5 s
cucumber-spring	4.5	13% = 0.5 s
cucumber-testng	1.5	20% = 0.3 s
cucumber-guice	1.8	15% = 0.3 s
datatable	0.5	(unused dependency) 0% = 0 s

Total build duration: 3min17 = 197 seconds
Total test duration : 23.5 seconds
Total Mockito contribution : 4.2 seconds (18% of tests, 2% of build duration)

By reducing the usage of Mockito, the test duration can be lowered with two advantages:

• this gives the developer a shorter feedback loop.
• the energy consumption is lower (green IT), which is important because the cucumber-jvm project is built often (due to PR and renovate bot). 2% is not a lot, but on the long term, it makes a difference.

✨ Do you have a proposal for making it better?

I didn't check in details, but for example in JavaBackendTest, the @Mock ObjectFactory and Glue could be replaced by fake implementations, which could reduce the class test duration by about 80%.

[mpkorstanje]

Yes. This makes sense. I would agree to Mockito replacements if:

1. Stubs implementations are declared in the test class.
2. Stub implementations are simple.

This will likely result in some duplication but that is an acceptable tradeoff.

[CharlesLgn]

Does someone made a study to use another mock library to see if there will be better performance ? (EasyMock/JMockit/...)