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.

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

I didn't tried with other mock library. The proposed solution #2767 replaces mockito by stub and fake implementations, which leads to a 7% improvement of the build time (that is, much more than the 2% expected).

I didn't tried with other mock library. The proposed solution #2767 replaces mockito by stub and fake implementations, which leads to a 7% improvement of the build time (that is, much more than the 2% expected).

I understand the principle of using fake implementation. However, I think that if you have an interface with 25 methods, the test class will be poluate with a lot of fake implementation, with also a lot unuse code.

That is why I questioned the use of other library

I agree that readability is generally lower when using stub classes with a lot of methods... This may be improved by having specific stub classes that are shared between test cases, but @mpkorstanje wanted stubs implementations to be declared in the test class.

I didn't found a lot of mocking libraries performance comparisons, but according to mockito/mockito#3288, mockito and Easymock have more or less the same performance.

I didn't found a lot of mocking libraries performance comparisons, but according to mockito/mockito#3288, mockito and Easymock have more or less the same performance.

As I understand, this is not what they said.

mockito/mockito#3288 (comment)

So you see that EasyMock shows 100x less average execution time. And that's very strange. Can you please check my benchmarks? Have I done something wrong? Or how can you explain that?

the person opening the ticket says that EasyMock shows 100x less average execution time.

EasyMock

Callable mock;

@Setup
public void setup() throws Exception {
        mock = EasyMock.mock(Callable.class);

	EasyMock.expect(mock.call()).andReturn("1").times(1, Integer.MAX_VALUE);
	EasyMock.replay(mock);
}

@Benchmark
public Object testEastMock() throws Exception {
	return mock.call();
}

Mockito

Callable mock;

@Setup
public void setup() throws Exception {
	mock = mock(Callable.class, withSettings().mockMaker(MockMakers.INLINE));
	when(mock.call()).thenReturn("1");
}

@Benchmark
public Object testMockitoInline() throws Exception {
	return mock.call();
}

Benchmark                              Mode  Cnt   Score     Error    Units
MockitoBenchmarking.testEastMock       avgt    5    46.058 ±   0.443  ns/op
MockitoBenchmarking.testMockitoInline  avgt    5  4428.439 ± 356.722  ns/op

but maybe I did not understand what @sergey-morenets is saying 😕

Alright folks take it easy on the bike-shedding. 😉

As is, I've picked up a few parts of this PR. But overall it is quite boring to review and quite important to get right. So it does not seem to end on top of my priority queue. Switching mocking frameworks would be equally tedious to review so I'd like to avoid that too.

@jkronegg my appologies for that.

As time passes, I'm less convinced that gaining 2-7% on build time is really important. It's a lot of development and review effort (either with another mocking framework or without mocking framework).

@CharlesLgn yes, there seems to a 100x difference when calling Easymock vs Mockito methods (I don't remember why I wrote that the performance is the same; maybe because the methods are in practice called only a few times?🤔).

@mpkorstanje I agree that the development effort would be better invested on #2902 (which makes run Cucumber 2x faster) 😉. I can work on it if you want (I know you would prefer to manage the issue with a full rewrite of cucumber-java8 but 2x faster with just some caching looks good to me).