This is missing a whole lot of cases, no?

Here's a few:

"The Giggling Sisters (10000) dir. Bob Bob, Bob Bobbet" <- The _ Sisters in wrong location, and surname Bob, followed by a Bob as first name
"The Giggling Sisters (10000) dir. Your Mom, Second Mom, and Also Dad" <- False? Because not exactly two
"The Giggling Sisters (10000) dir. The Sisters, Those Brothers" <- starts with The, contains brothers/sisters, ends with Brothers
"The Giggling Sisters (10000) dir. A B, C B (20000) dir. The Sisters, Those Brothers" <- Weird title. permissible?
"The Giggling Sisters (10000) dir. The A Sisters, The A Sisters" <- A Sisters mentioned twice, thus should be False

Description mentions "Several guys" but I don't see the word "and" used anywhere in the test code at a glance. That'll cause people to write code for this - except it.. isn't part of the task?

• Sample tests are missing the imports for test framework and solutions

• Description does not mention whether a middle name will be expected, should have mentioned what constitutes a name and its form, which in this case is ${firstname} ${lastname} only

• Also these tasks have been done to death (Similar ones listed below) --> Basic string parsing with direct solution giveaway just by reading the description !

  1

  2

  3

  4

I'll check it out, thanks

Failed tests should show inputs to help with debugging, either with test titles, or with assertion messages (see example kata for ideas).

@Blind4Basics as well as the actual tests which would surely throw an exception for non-existing self.parts, actually (got it myself during completing the kata).
At least, according to the lore and such, that could've been considered as a slight-ish hint... that, or you can go over it in other ways tbh

So yeah, honestly I don't think the comparison tests having the MockObject with parts is a big problem, especially with the fixed initial solution (unless I'm missing something at 9 AM...)

I'm more bothered with comparison tests that rely on the existence of the parts attribute, actually. This is not bad per se, but this is totally white box testing.
I was also annoyed with the _parts vs parts thing, but this is mostly because of the non existence of specifications. A "private" (underscore thing) against a frozen public propety (without the underscore) is quite usual in python.

Yeah, honestly I was considering that as an issue before beta approval but thought it would not be pretty crucial...

For now changed in the initial solution self._parts to self.parts as more suitable with the actual tests, thanks for your feedback :)

Great kata. One tiny stumbling block for me was that the init assigns to self._parts, but then the tests look at self.parts. I assumed they'd be checking for immutability on the underscored version. (Or maybe they're hinting that we should keep both separately...)

Map Max: Fury Road

This is a good one for testing performance but not too harshly

oops, i left the import in there

This could be an interesting pattern-matching problem, but right now it's just a trick about whether you read the order of two very similar words

I also saw the don't import ast or a module that depends on it message when I hadn't imported anything. In fact, you can reproduce this in one line by writing return x and getting a NameError because there is no x. So there must be something that wrongly triggers that message with Python NameErrors, at least.

the changes from indexing won't work as its a parameter

Why do you say that?