> tests that run every single build even when nothing checked by them has changed
Oh yes, because we can always be sure that a change in one place will never cause a test in another place to fail.
Oh yes, because we can always be sure that a change in one place will never cause a test in another place to fail.
Or stuff like reordering a piece of code which should be a no-op, but causes two expensive operations to be run simultaneously on the same die at runtime, resulting in a CPU under voltage event which triggers a reboot. I ran into this exact problem about 6 months ago. We could argue about whether the CPU, motherboard, or power supply vendor was out of spec, but in the real world with deployed hardware that doesn't matter. You revert and run the code that doesn't trigger a reboots during high work loads.
Having a test suite catch this before you deploy to production is a good thing.