Comment by oneeyedpigeon
15 hours ago
What kind of tests would this break? Aside from the advice on the page itself (which, iirc, is new anyway), i'm wondering why any testing would actually involve the contents of design of the page. Just a weird 'sanity' check?
People depend on all sorts of weird stuff working exactly as expected. https://www.hyrumslaw.com/
As an example, depending on "man -w" not outputting anything to stderr: https://unix.stackexchange.com/questions/405783/why-does-man...
Our saas had an internal-use, undocumented, publicly accessibly but not publicly used (by us) health endpoint that included an internal version number.
We removed the version and a few customers complained we broke their stuff.
I landed a massive database upgrade on a payroll system years ago, end-to-end standardization, cleanup, and improvement with a seamless rollout.
Our back clapping was interrupted by an angry customer phone call. One of our customers had gotten access to our internal schema and had a massive reporting setup in Access solving most of his needs.
I ended up converting his reports using some internal tools we had. Customers will grab anything to give them.
[The caliber and depth of his reports were such I wish we would have bought them instead of making me spend months building out our own reports.]
2 replies →
The API surface is what’s exposed, not just what’s documented.
This is probably an even more important principle in the age of LLMs.
While not the same thing, I was once stung by a test failing because a dependency of a dependency decided on a minor version bump that foo@example.com wasn't a valid email address.
Probably akin to: https://xkcd.com/1172/
I knew what this was before clicking on the link, but for a lot of people, it may be a 1053.