I just worked through the Cars, Assemble exercise and encountered something that I think of as a unit test anti-pattern.

In the current implementation the assertions that compare doubles are in the form: assertThat(Math.abs(carsAssemble.productionRatePerHour(9) - 1591.2) < epsilon).isTrue();
which means when the test fails the student gets an unhelpful message: "Expecting: <false> to be equal to <true> but was not."

I thought it was standard to use the AreEquals double-with-delta form: Assertions.assertEquals(1591.2, carsAssemble.productionRatePerHour(9), epsilon);
which reports the same failure in a more informative way: Expected: 1591.2 Actual: 1989.0

The C# track does seem to have the more informative test pattern: Assert.Equal(1591.2, AssemblyLine.ProductionRatePerHour(9), precision: 1);

Iāll make the changes if itās worth updating - I did convert the tests locally when solving to get the added information anyways

Note the difference in the epsilon boundary between current implementation and using assertEquals(double, double, epsilon). I donāt think it will cause any existing solutions to fail but honestly donāt remember the depths of double comparisons and if the existing epsilon is the right precision.
My gut is that the epsilon value doesnāt need to be 7 digits and for the values being calulcated in this exercise an epsilon of 3 or 4 digits would be precise enough.