The “Tree Building” exercise expects one of the exception messages to be “Node parent_id should be smaller than it’s record_id.” but this is grammatically incorrect: “it’s” is an abbreviation of “it is”. The correct possessive form is “its” with no apostrophe.
Hi @xanni,
Thanks for reporting this. I’m not sure I want to invalidate the ~1800 published solutions for this exercise over an apostrophe, but I will add this to my list of things to look at after our tooling upgrades are completed. 
Yeah, that’s entirely reasonable. I have a short-term and a long-term suggestion: in the short term, acknowledge the error in the problem specification and confirm that the erroneous message is the requirement. Just like in real life code! And in the long term, it would be great to have a way to version the tests so that solutions are only required to pass the version of tests that existed when they were submitted.
Having a test that is “fuzzy” in that it accepts enough of the message that is required can avoid invalidating all of them.
Having a match that includes “Node”, “parent_id”, “smaller than” and “record_id” in the message that comes when the exception is raised will allow for a fix for the grammer, while focusing on the idea that “it has information that was likely understood”.
Do we really care that much that this exact message is passed, or can we state that it is wanted, while allowing for some variances?
Custom exception? You’ll probably need to reference that concept in an instructions append, but I think that’d be more useful than having a student be able to pass the tests with an message like “record_id smaller_than Node parent_id”. That’d satisfy the expected pieces being in the message, but the order would give it an entirely different meaning.
We’d need to deprecate the existing test and add a new one to replace it, and then that change will get propagated to 77 tracks as maintainers have time. Some tracks have test generators so the change would probably be straightforward, but others won’t so that’d be a little more work by the maintainers. We tend to be protective of maintainer time since there aren’t a lot of them and several maintainers manage multiple tracks on their personal time. A few minutes per track adds up just to make the changes and then someone needs to review the PRs as well. That’s time the maintainers could spend doing other track tasks so it’s a balancing act really.
The student solutions are versioned in fact. They’re pinned to specific versions of the exercise documentation and tests and need to be updated if there are more recent versions of either. The invalidation alerts the user that this needs to be done. Updating the exercise pulls in those updates for the student and reruns the tests.
Custom exceptions were already in the previous exercises, so that’s an excellent solution.
We already do not prevent hardcoding of solutions to pass tests, it is not meant to be “fool” proof if people want to act the fool.
But also, similarly, if it is mostly the exact thing, we can fuzzy match “{it’s|its}” and allow it to pass either way, with the rest of it being intact. It does not force correct grammar, but then the grammar police are not on the payroll.