Wow that is embarassing. Thank you for pointing out my error. I was certain that I had counted all 15 requests in my solution. I am ashamed of myself.

That is only 14 requests. I figured you'd be too focused on checking that they didn't overlap to notice that one was missing, but by distributing them manually you wouldn't lose one of them due to some oversight or bug in the code that you wouldn't manually reproduce since you'd be aware of every step carried out.

I appreciate your patience with my ignorance. I solved the above example by hand and came out with the exact same taxis as above:

taxi 1: (3, 10), (14, 22), (26, 30)
taxi 2: (8, 10), (16, 26), (27, 29)
taxi 3: (9, 18), (19, 20), (21, 30)
taxi 4: (16, 26), (29, 30)
taxi 5: (17, 25), (29, 30)
taxi 6: (19, 28)

How are these not "distributed" correctly?

Yes, but you didn't distribute the requests between the taxis. Yes, check it by hand. Better yet, solve it by hand so that you are actually checking that it's solvable rather than looking at the solution and failing to find a problem (which doesn't mean there isn't one)

I listed the six taxis above. The number of requests is small enough that it can be checked by hand, and while I may have missed something, I do not see any mistake. All 15 requests are satisfied with the six taxis that are show in my post.

You won't be able to distribute them between six taxis so it should be easy to figure it out why that's wrong

My code passes the basic tests and most of the small random tests, but on some tests it says I am off by one taxi. In the example below, it says there should be 7 taxis. I don't see how they are getting 7 taxis. What am I missing here?

Requests:  [(19, 20), (9, 18), (8, 10), (17, 25), (27, 29), 
            (16, 26), (29, 30), (26, 30), (19, 28), (21, 30), 
            (29, 30), (19, 28), (3, 10), (16, 26), (14, 22)]
Number of requests:  15

Number of taxis:  6
Taxis:
[(3, 10), (14, 22), (26, 30)]
[(8, 10), (16, 26), (27, 29)]
[(9, 18), (19, 20), (21, 30)]
[(16, 26), (29, 30)]
[(17, 25), (29, 30)]
[(19, 28)]

The fork was already approved by someone. However, I have now made it into blocks as per your suggestion in this fork.

approved

Haskell translation

approved

this has assertions outside it (which the current/old version also does)

    def check(a, b, c, d):
        for _ in range(a):
            requests = [create_request((b, c)) for _ in range(d)]
            reqs_copy = requests[::]
            test.assert_equals(min_num_taxis(reqs_copy), mnt(requests))

    @test.describe("20 small sized random tests.")
    def basic_test_cases():
        check(20, 1, 30, 15)

also not a fan of the a b c d's because it's very difficult to see what's what. but. whatever, I guess. I'll approve after the describes around the check calls are changed into its

do not redefine the Fighter class, it is preloaded for you. redefining it tampers with the tests, which should not happen. re-raised an issue about that above with a proposed fix

JavaScripts tests are vulnerable to (possibly accidental) redefinition of the fighter class.
fixed here along with:

• better assertion messages
• using a modern JS class for the Fighters

There are ways to check whats tested on Codewars: https://docs.codewars.com/training/training-example#debugging-a-kata