Happy to help with this myself!
I have noticed a few people get the tests passing simply by splitting by “_” as well as spaces and dashes. We could have tests to catch those things, as well as checking that punctuation is being correctly removed, like this:
“he_llo world” (should return “HW”)
“hello …world” (should return “HW”)
“hello … world” (should return “HW”)
“hello ??? world” (should return “HW”)
As a general remark, we don’t aim to be exhaustive. Which is also why not all exercises have error handling.
@IsaacG Thank you for the link! I’ll try to make the benefits clear when proposing changes.
I understand we do not aim to be exhaustive with our tests (I have just changed the title of the thread to make it obvious that that is not the issue I really have), and I agree this is unimportant in the grand scheme of things. However, I think people go to “Community Solutions” to look for ways their own approach could be included, and check “Fewest number of lines” to see cool tricks they may have missed.
Many of the shortest solutions to that exercise (including the shortest one) do not conform to the spec, which I think is unfortunate, makes finding relevant solutions harder.
In this particular exercise, I think slightly more comprehensive test cases would allow more uniformity in the passing solutions, so they can be compared more fairly; it would guide students to look into stuff such as filter{}, mapNotNull{} or dropWhile{} by making them face the interesting issue of “What if you want the first letter of a string but it does not start with a letter (and may not contain any letters at all!)”.
I noticed this error by mentoring this exercise, so I am also mentioning it quite a bit to mentees (I’d say most approaches I’ve seen treat _ as a separator only to get the test to pass; it looks like the tests is driving the perception of the spec here, so I think better slightly more comprehensive tests would drive the point of the exercise better).
I am not in a position to weigh in whether this is worth nullifying some currently-passing answers (I believe it might be ok from a “moral” point of view, since we would not be changing the spec, just improving how the tests verify it), nor the environmental costs associated with it (not sure how much computing power would be needed here).
Thanks @NachoGoro.
There are two angles:
We have the same questions often around unicode and other things. As this is an exercise coming from problem-specifications, changes to it effect things on all tracks. So it’s important to think about the wide consequences of making the exercise harder etc.
I’ve moved this to “Building Exercism” with the hope that some other maintainers can give their thoughts with relation to their tracks. I’d like to emphasise that there’s no right/wrong here - it’s a decision based on tradeoffs. But if people outline their opinions, we’ll either find a consensus, or Erik and I can make a decision. I don’t think there’s huge value in debating though, so just hearing people’s opinions would be my preference here 
Acronym tests are not exhaustive enough to stop answers not conforming to the spec from passing
Given that the tests are the spec, if solutions pass the tests they also pass the spec.
My preference is to leave this as is. I don’t think there is a need to introduce additional “word separators”. The tests have enough cases as is.
Then the first letter of the string would still be the first letter of the string, right? No problem there, since here you are saying that the first letter of the string led by something other than a letter. Something like this:
“3l337 5934k”
According to the example code that I am running from the repository, this does indeed return “LK” and that seems compliant with the the first request “we want the first letter of a string but it does not start with a letter” Which reduces to “we want the first letter of a string” since anything that is not a letter that precedes the first letter is not the first letter.
So this “works” exactly in that way, using the example.rb file to get an answer.
I might say something like:
However, while the tests allow this, and that is what the example solution does, I would consider this a “stretch goal” to go for while mentoring, or as a “consider this” moment after solving what is there.
I see Jeremy’s point that debate is not the way to go, so I’ll leave it for the maintainers to discuss.
Just to clarify my point of view, though: the written Instructions state that all punctuation which is not blank spaces or dashes should be ignored; the tests allow solutions which do not ignore them to pass, and the philosophy is that tests are the spec, and therefore it is not really a problem. The issue for me is the mismatch between the written instructions and the laxer tests, which makes it look like there are two specs.
My point is that both should be put in sync. I suggested updating the tests to make them stricter, but maybe the written Instructions could be updated instead to be more lax.
I’ll leave it here, thank you all for looking into it!
My stand is that if most general solutions has to change to fit this extension to specification, so am I against it. Meanwhile the instructions could get some more love that makes it more interesting if that includes a rewording to be more clear is that not something I have any problems with.
I’m in agreement with Isaac and Meatball. For the Python track, upwards of 7,000 solutions might fail if we change the tests, and I am not sure that it would be adding much in the way of learning/problem-solving. Rephrasing the instructions might be better in this case.
I think if we’d like to drill students on the removal of punctuation and/or punctuation with unicode (and the selection of various substrings), we should create a new practice exercise to do so. Maybe something similar to the log levels exercise, but with more and varied separators, or a variation on Micro-Blog that had some different criteria and characters.