I agree that tests and automation are probably the best things we can do to validate our code and author of the PR should be more responsible.
However they can't prove that the code works. It's almost the opposite:
If they pass and it's a good coverage, then code has better chances to work.
If they fail, then they prove code doesn't work.
If you integrate with a third party service and their environment is slow, because it's not a production environment, your tests will fail due to timeouts. How would you fix this?
One way I would think is to not go against their service; create a similar service and run it according to your SLA. But then, you have to make sure contracts are in sync, so you need to verify contracts from time to time.
At some point I made a news-articles site and I took that approach rather than databases: the owner would write XML files for each article that would be pretty simple: e.g. with tags like `title`, `image` (left, right, hero)`, some asides and some basic formatting for the body of the article, and XSLT, templates and CSS would make it a proper page. All the magic happened in the browser. I still think that's pretty cool.
That's pretty much what it was designed to do. You could push it pretty far too. Relational databases at the time all implemented XML types, so you could have XML all the way down, and XSLT is how you'd go from point A to point B.
Yup, today I was looking on some examples of AWS CloudFormation templates and I saw version 2010-09-09. Instantly, I thought the webpage I was reading must be old; so I opened the docs. In the docs, I see "The latest template format version is 2010-09-09 and is currently the only valid value."
Last version was 10 years ago and this service is one of the core AWS services, so it's definitively not abandoned.
That's just protocol versioning - it means they haven't made backwards-incompatible breaking changes to the template protocol, not that the features haven't been updated in 10 years.
