Closed ivanzy closed 2 years ago
I would say it is better to be verbose than vague. assertUniqueID
does not specify which id it verifies the uniqueness, so I would name it assertThingDescriptionUniqueId
, which is as verbose as the current name.
Don't be afraid to make a name long. A long descriptive name is better than a short enigmatic name. A long descriptive name is better than a long descriptive comment. Robert C. Martin
Ok then I think we have a consensus here: assertUniqueThingDescriptionID
(I think putting Unique first sounds better in English but I am not sure how to apply for the English advective force order here: The rule is that multiple adjectives are always ranked accordingly: opinion, size, age, shape, colour, origin, material, purpose ) .
I've also noticed that we have requireValidThingDescription
method in the same class. We should decide whether to use assert
or require
in such cases and write the final decision here (I'm opening an issue to tracking this down)
The code is great. Thanks for the work! If possible, it would be important to add a couple of failing tests (for both the PUT and PATCH) when the client tries to change the TD
id
to an existing one. Basically check the correct behavior of thecheckDuplicateThingDescriptionId
in the respective two cases.
Done in commit #2dc14bb .
To maintain consistency, I will open another branch to do it. That way, we have a 1-to-1 relationship between issues, branches, and PRs.
When a TD is updated (PUT or PATCH), the
internalThingDescription
urn is updated as well. Additionally, there is an additional check to ensure that the new id is not a duplicated one. The new exception is: