Unit testing constants?

 I have the following constants defined:

Those constants are used locally in separate parts of the code piece. (The RDS one is used in LIMIT clauses for SQL, while the commercetools one is used in a SaaS offering's API) And that's it.

We could easily limit 2000 lines on the RDS side without any problem. However, commercetools won't send back more than 500 items in a query, no matter what.

It's not the end of the world. However, in that case, the logic on the commercetools side needs to splice the input array to no larger than 500-piece chunks, make requests that way, and stitch everything back together. Doable but also avoidable if we just set both to 500.

Setting up these variables separately ensures that both classes are still isolated, etc. But what do I do with this quite important bit of information that's implicit in the setup and that has the potential to break the whole import code if ignored?

I could document it, but we all know that's the last place a developer would look for - myself included.

So the real answer is: unit tests

And that is why we have this seemingly irrelevant unit test in place. The most ironic part is that no amount of tooling (like code coverage) would ever flag the need for this test. I would even venture that some tools would call out that this is a "useless" test case for two constants...

 If you have a better idea of how to solve this, let me know, please!