[6LLvveMx2koXfwn]

> For instance recently I made a small change to a table and a coworker pointed out that there was a microservice I wasn't considering that wrote to that table that would break

If code reviews are important, where does testing sit? Presumably if the coworker had not been part of the code review something would have stopped the breaking change making its way to prod?

[chii]

> something would have stopped the breaking change making its way to prod?

or a prod outage causes the knowledge to be experienced.

[marcosdumay]

I'd guess testing is done only for the software being deployed, not for that other microservice.

At least, that's what people do by default.

[skydhash]

> If code reviews are important, where does testing sit?

Testing is for general boundaries. If you have a formalized specs, investing in an harness and writing a lot of tests is worth it.

But more likely in a corporate system, fully documenting everything is a huge hurdle by itself. So your best bet is to gather everyone that is related to a change and let them evaluate its impact.

[nunez]

Before the PR is cut, before the PR is sent to review (so that time isn't wasted on low-valuw bugs and problems --- engineers are expensive!), pre-merge and pre-release.