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.

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.

Finding the number of elements in an arithmetic progression based on its sum is not new.

Nice kata. A couple recommendations:

• increase the number of random tests to something like 50 or greater
• add additional fixed edge cases like (4987653201,20)

When I initially approached this problem, I misinterpreted offset to be n-th iteration, rather than starting from the value >= offset. The Description is fine; I just misread. I bring this up to gauge interest in a kata similar to this, but where offset refers to the n-th iteration offset.

Returned price doesn't match expected value.

It does not help to debug
Please use assertEquals([message ,]expected, actual) instead of assertTrue...

Sample Tests expect wrong results

BigInteger.valueOf(3), BigInteger.valueOf(4)), new BigInteger[]{BigInteger.valueOf(2), BigInteger.valueOf(4), BigInteger.valueOf(32)}

3/4 != 1/2 + 1/4 + 1/32

BigInteger.valueOf(4), BigInteger.valueOf(6)), new BigInteger[]{BigInteger.valueOf(2), BigInteger.valueOf(6), BigInteger.valueOf(72)}

4/6 != 1/2 + 1/6 + 1/72

Tests expect BigInteger[] but initial code is public static List<BigInteger>