Fixed tests added

I added fixed tests and the testcase with 0 added to those tests.

The random tests generate votes with number of votes equal to 0. If it's intended behavior:

• this isn't specified in the description
• this should be present in the example/fixed tests

(FFS WHAT ARE DOING THE OTHER BETA TESTERS !???)

The example tests have to be present at the beginning of the full test suite.

(FFS, what are doing the other beta testers!??)

ok, I read "all votes" as "all people", actually. Not sure if it's on me or my frenglish or anything else.

The whole problem is a mix of tiny "misunderstandings" accumulated on both sides (reader/writer), I think.

Basically, what you're asking for is something along the line of:

Find all the possible solutions and merge them to output only the votes/shares (pick your prefered wording here) that are sure/non ambiguous.

I'd also detail the "some votes are ambigous" case to highlight this, so that you can avoid misinterpretations of the task.

edit: ...and if I understand correctly the expected output of this test, it seems to me this is a direct contradiction with this sentence of the description:

All vote options must be included in the result dictionary. If no votes can be definitively attributed to an option, its value should be an empty set.

I think it is quite clear, and I don't know how it could be misinterpreted so we probably understand the same sentence differently. I also am not a native speaker and don't know how to make it better :/

The way I understand what I wrote:

All vote options

(for example "Yes", "No")

must be must be included in the result dictionary

so the resulting dictionary must have all the keys. { 'Yes' :... , No:... }

If no votes can be definitively attributed to an option,

It means that for example we cannot deduce that any particular person has voted the option 'Yes'.

its value should be an empty set.

then the value in the result should be empty set. For example: { 'Yes': set(), ... }

But this doesn't resolve the issue: the description is currently incomplete at best, or wrong at worst.

(well, could be considered another issue)

Both examples are indeed similar. In the second example there are two possible votings that could result in 'No': 13157, 'What': 16375.

They are:

  Emilia:No, Emma:What, Mia:What, Sofia:No,   Elena:What, Lia:No,   Olivia:No,   Lina:No
  Emilia:What, Emma:No, Mia:What, Sofia:What, Elena:No,   Lia:What, Olivia:What, Lina:What
         !=         !=      ==          !=          !=        !=           !=         !=   

So Mia is the only person who's vote we can deduce. So the correct answer is 'What':{'Mia'}

You were correct about the test code being vulnerable to user code modyfing input structures. I have fixed that.

side effect: I actually think you should give an actual explanation (in the description) of the "some votes are ambiguous" case, because I think that's what I'm missing.

edit: ...and if I understand correctly the expected output of this test, it seems to me this is a direct contradiction with this sentence of the description:

All vote options must be included in the result dictionary. If no votes can be definitively attributed to an option, its value should be an empty set.

A first step would be to add a very first test stating "a solution exists but your code didn't find it", or equivalent. Currently, one gets feedback about the groups when the default output is returned, which is also misleading.

Also, double check the messages are built with data structures that have not been mutated, otherwise they are pretty useless (I'd bet on that, currently)

Are you sure the example tests are correct...? In the "some ambiguous" case:

shares = { "Garage Place 1": 423, "Garage Place 2": 437, "Large Garage Place 1": 600, "large Garage Place 2": 600, "Apartment 1": 2079,  "Apartment 2": 1368, "Apartment 3": 1333, "Apartment 4": 1691, "Apartment 5": 1469 }
                                   ^^^^^^^^^^^^^^^^^^^^
votes = { "Yes": 1037, "No": 8963 }
                 ^^^^
expected = {'Yes': {'Garage Place 2'}, 'No': ...}
                    ^^^^^^^^^^^^^^^^

Similar (?) kind of problems in the full test suite:

shares = {'Emilia': 891, 'Emma': 9695, 'Mia': 3218, 'Sofia': 3813, 'Elena': 3462, 'Lia': 3088, 'Olivia': 3737, 'Lina': 1628}
votes = {'Yes': 0, 'No': 13157, 'What': 16375}
invalid response for voting option What. Expected: {'Mia'}. But was: set()

How could Mia be the only person in the set while 3218!=16375?

Double check the assertion message are built correctly (like, they are showing the actual returned set, as implied by the message,eand not the difference of actual vs expected or something like that). Or maybe actual and expected are swapped?

Great kata...

Added this sentence to output part:

All vote options must be included in the result dictionary. If no votes can be definitively attributed to an option, its value should be an empty set.

"e.g.": I'm not english native, sorry => ok.

About the spec, what I meant is that you should state the output kind you expect. Formally, anything from an ampety dict to None or what you currently use could be acceptable. Or even, raising an error. => Just clarify it's a dict with empty sets.

You can close the issue after that.