Why does one more Scenario break Cucumber - cucumber

Question

Everything was going fine until I added the SleepWithInterruptHandler Scenario to my Lag.feature file
Feature: Induced Lag
There are many reasons we might want to induce lag into our code, such as for
testing, benchmarking, experimenting, etc.
Scenario: Minimal Duration
Given a minimal Lag
When I compute the minimal duration
Then it should equal zero
Scenario: Definite Duration
Given a definite Lag
When I compute the definite duration
Then it should equal the minimum duration
Scenario: Random Duration
Given a random Lag
When I compute the random duration
Then it should not equal either the minimum or the maximum
And it should not be outside the range
Scenario: Sleep With Interrupt Handler
Given a task with random Lag
When I start it
Then it should start normally
And it should complete normally without interrupt
While the other scenarios continue to run fine, with the last scenario I get the infamous
io.cucumber.junit.platform.engine.UndefinedStepException:
The step 'a task with random Lag' and 3 other step(s) are undefined.
You can implement these steps using the snippet(s) below:
There is nothing at all wrong with my steps class for the scenario, and google search suggests something to do with glue, but that does not help. The last scenario fails
under both Maven and IntelliJ.
public class SleepWithInterruptHandler implements En {
Duration minimumDuration = Duration.ofMillis(10);
Duration maximumDuration = Duration.ofMillis(20);
Lag randomLag;
Duration randomDuration;
AtomicInteger value = new AtomicInteger();
Lag lag = new Lag(minimumDuration, maximumDuration);
Runnable withInterruptHandler = new LagTests.WithInterruptHandler(value, lag);
Thread regularThread = new Thread(withInterruptHandler);
SleepWithInterruptHandler() {
Given("a task with random Lag", () -> {
assertEquals(0, value.get());
});
When("I start it", () -> {
regularThread.start();
});
Then("it should start normally", () -> {
// Wait a little time, but not after our task ends...
Thread.sleep(minimumDuration.dividedBy(2));
assertEquals(1, value.get());
});
And("it should complete normally without interrupt", () -> {
// Wait for our task to end...
regularThread.join();
assertEquals(3, value.get());
});
}
}
public class DefiniteDuration implements En {
Duration minimumDuration = Duration.ofMillis(10);
Lag definiteLag;
Duration definiteDuration;
public DefiniteDuration() {
Given("a definite Lag", () -> {
definiteLag = new Lag(minimumDuration);
});
When("I compute the definite duration", () -> {
definiteDuration = definiteLag.getDuration();
});
Then("it should equal the minimum duration", () -> {
assertEquals(minimumDuration, definiteDuration);
});
}
}
Full project can be found at https://github.com/kolotyluk/loom-lab
However, the more important question is, why is Cucumber happy with 3 scenarios but not 4?

Answer 1

Okay, the problem was that I forgot to make the constructor of SleepWithInterruptHandler public..., so many thanks to M.P. Korstanje for the answer.
Stepping back a bit, this is a common problem I see with some software. The diagnostics do not fit the root cause.
io.cucumber.junit.platform.engine.UndefinedStepException:
The step 'a task with random Lag' and 3 other step(s) are undefined.
You can implement these steps using the snippet(s) below:
Followed by a bunch of code examples, that when I copy/pasted them... did not work either.
Korstanje was right, I was jumping to conclusions, my conclusion was that the Cucumber diagnostics were telling me something meaningful, when they were not, they were misleading. The other conclusion I jumped to was that Google search would tell me something meaningful, but it largely did not either, because it found a lot of solutions that involved glue and there were so many of these search hits, I concluded that the glue problem was infamous, and I concluded that my problem was a glue problem.
Now, there are probably two camps of thought on this
That I am some sort of idiot for jumping to conclusions and making a lame
mistake by not checking that my constructors are public too.
That we could and should invests in better diagnostics, that once we
understand a problem, especially the root cause, we can look for such
problems, and make that part of the diagnostics, or a least have the
diagnostics suggest multiple problems with multiple solutions.
As a further example, in the last year I have had to learn Gradle. After more than a decade of using Maven, and then SBT, I have found that Gradle's diagnostics are very immature compared to Maven. I have spent countless hours chasing down Gradle problems because the diagnostics were so very wrong and misleading, and confidently so. SBT... well I won't comment...
Now, I have not tried this in Kotlin or Scala yet, but I should, because in these languages I think the default for constructors is public, which is why I may have forgotten that in Java they are not...
Sorry for the soapbox, but I had an ah-ha moment when I realize the simple problem, and could related it to a larger problem, a larger pattern of how software is designed and implemented, a larger pattern of where I spend my debugging time these days...