Fair enough. When I have a moment in the next few days I'll make changes following this and the other comments, and I'll see which cases fit better in the tests vs which ones might be better ruled out in a spec.

If we go by the "real movies" benchmark then realistically all of natans cases other than the 4th (and maybe 3rd) are applicable and I can provide a movie that fits each of them.

What actually needs to be done is to have a properly defined spec laid out for the inputs. What the spec is is entirely up to you, but I feel like permitting as many edge cases as possible is a good thing.

I hesitate to say yes because I haven't offered a solution to the problem. With that said you're welcome to do whatever you want with them.

Okay, sounds good. I took the "and" out of the example with the three guys, which was a mistake. They should be all simply comma-separated, and I don't want to have to worry about "and" or "&" or Oxford comma or not.

I added notes in the description to narrow some of these questions, and I'll add some more test cases. Would you be okay if I copied yours from this post above?

Most of the published solutions are wrong in obvious ways, some of which are explicit requirements that aren't tested at all.

If a new movie comes out, our solutions should be able to correctly categorize it, right? So long as it adheres to the format, but otherwise regardless of how it reads. Bit of a broken clock otherwise.

Btw I'm not saying my test cases should be added. They're only there to demonstrate the mismatch between the tests and the description, and what effect that has on the solutions. I'm pointing out the problem, not offering a solution.

My passing solution thinks these are siblings: "A film (1999) dir. Bob Berg, Bob Iceberg" and it should get caught for it (or any of its other shortcomings, my solution is not good - "Hello, I am bob. (1999) dir. Some Guy, Sam Hello" is another one it says has siblings)

I wanted to use real movies, and to have the random tests generate only the kinds of cases that came up in the real-world examples. But maybe that's just me being silly.

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