Julien Kronegg
Julien Kronegg
I can confirm that all step expressions are recreated at each test scenario (for one of my project with about 400 test scenarios, expressions are recreated about 400 times). Also...
> why it's not merged yet? There is no merge on this library since 2020, maybe the maintainer has new duties... As an alternative, you could copy/paste the `StringUtils` class...
I agree that "Then" step definitions should have at least one assert. But asserts should be optional for "Given" and "When" step definitions: - "Given" step definitions defines the testing...
The workaround is to have the two files `cucumber.properties` and `junit-platform.properties` with the same content, so that Cucumber runtime configuration is the same no matter the execution method.
I added `@ConfigurationParametersResource("cucumber.properties")` and it works. To summarize the different behaviors: |Run with | `cucumber.properties` + `@ConfigurationParametersResource("cucumber.properties")` on Cucumber test class | `cucumber.properties` + same `junit-platform.properties` | `cucumber.properties` only |...
I removed all mockito usages. I'm happy with the performance improvement on interactive tests, ~but a bit puzzled by having the same build duration with or without mockito when doing...
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,...
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...
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...
Having a `DefaultDocTypeTransformer` is not very flexible because you can have only one. Would it make more sense to have instead a DocType transformer/converter which is able to convert more...