The instructions suggest that there should be a way to give a name and indicate that the person doesn’t like cookies. The tests and completed solutions do not include this situation.
I think you’re misunderstanding the instructions. Could you show the part you understand says that please so we can look at it?
I definitely misunderstood, but I think it’s because the instructions were written poorly. I assumed we were being given our friend’s name and whether they liked cookies or not. “If your friend doesn’t like cookies, you give the cookie to the next person in line at the bakery. Since you don’t know their name, you will say you instead.” The logic about whether the friend likes cookies or not is happening outside of the TwoFer class/module, indicated by whether a name is passed to TwoFer or not. I assumed that all logic described in the instructions was my job to do. Since the class/module was initially empty, and the tests needed to be edited, more guidance in the instructions would have been helpful.
I’ve seen similar questions like this before, the general opinion is that the highest authority in an exercise is the test suite. Instructions can’t and won’t cover everything, so always refer to the test suite.
The idea that the class or module is empty is also a bit limited as this exercise is also solvable without either of those things being defined.
So leaving it open to exploration is a feature as well.
This is a poor excuse for a badly written instruction. Giving the user a very open direction to share a cookie with another person and return a string including a name if known or ‘you’ if not has many, many solutions. All of which likely fulfil the instruction but then to test for only one specific solution is ridiculous.
It purposefully tests for a specific outcome, probably not for a specific solution, because we do not want to nor do we intend to, drive the solution. The result of any solution is as valid as any other solution.
I am not sure how to take the “ridiculous” statement. I agree that it is, but I am not sure it is for the reasons you are thinking.
I am curious though, as to what specifically is “poorly written”. Having a concrete example here means we can work on it. Or perhaps that you may be seeing a set of instructions that are not yet updated. But we can not know for sure until we see that shown.
Out of every 500 passing submissions, over 250 are unique. So definitely not one specific solution.
Exercism uses TDD - the tests are spec.
Regardless, the central description was updated months ago. As @kotp says, maybe some tracks haven’t updated yet.
Maybe you could provide some helpful information such as which track you’re working through. The Ruby track (which is what this thread is about) was updated in March. Maybe you’ve not updated your exercise to the latest version? Maybe you’re working on a different track?