assertEquals uses BigDecimal.equals, which requires the precision to the same too, which can be problematic.

But even then, a custom message should be provided instead of this.

all suppliers need to have a different price

Reference solution violates this constraint in even the simplest case:

demand: {{"1", "1.20"}}
supply: {{"1", "1.20"}}
capacity: 1
expected:<1.20> but was:<1.19>

Random tests are setting 1 test block per random test and creates many duplicate methods per random test case. Why not just use a for loop?

Some tests are supplying prices with incorrect scale and sort of expect solutions to fix them, such as:

    @Test
    public void sameResultWithDifferentPrices() {
        String[][] demand = {{"75", "15.00"}, {"50", "16.00"}, {"16", "25"}};
        String[][] supply = {{"100", "12.50"}};
        pickYourPrice(demand, supply, "25", "25.00");
    }

There is a conceptual problem with the kata: the kata asks us to find the outline, which is defined as

The outline is the sum of the three sides of the outer triangle

And the reference solution assumes that the outline is a triangle, and calculates the two sides accordingly. However, the two sides of the triangle are not straight lines: they are triangle sides displaced vertically by card width. The actual outline is hence all the card width and card thickness combined, not a straight line from the apex to the two corners. This is very obvious once card thickness becomes comparable to card length.

why did you republish it, then?

tests will use a precision of 6 decimals when comparing floats, to avoid comparison issues round your final calculations also to 6 decimals

Comparing what floats? Round what?

when comparing 2 floats rounded as specified in previous rule, a delta of 0.000001 is used:

Is used where?

It's not clear what exactly should be within what bounds. There are various values that can be used to solve the problem. Should distances and internal angles be within 1e-6? Should something else? Mathematically, there are solutions that don't calculate those. Either there should be an exact definition of what is considered a regular polygon or there should't be tests with almost regular polygons that are considered not regular. (Note that you compare only adjacent values in your solution rather than all values.)

Hi,

In the tests floats are rounded to 6 decimals, and tested with a delta of [-0.000001..+0.000001].
I woill add a comment to the description.

thanks

What precision is expected? The sides of [{0, 10.392305}, {6, 0}, {-6, 0}] are [144.00000321302502, 144, 144.00000321302502].

The tests in the python 3.6 version ignore the offset. (Sample test work fine, the actual tests need fixed)

you're right, I'll add some more tests
and rewrite my solution
thanks

The current Elixir reference solution (brute force) is not viable. It times out before it can complete a single edge case such as (4987653201,20), or (2987654301,10), etc.

Right thanks :)
fixed it now and learned something new in python