How do you test your system's response to error conditions? Do you have hooks in your integrated system to force errors (throw exceptions, violate contracts, etc.)?

In some cases, yes.

You can do things like set up scenarios you know won't work, such as connecting to machines that don't exist or sending the wrong parameters.

The main thing is if the external inputs can't be made to "violate a contract", the internals aren't the problem.

Ultimately, it depends on what you are building. Simple CRUD web applications are different from systems development type applications in many cases. Many of these classes can be more easily mocked out.

Often the breaking change you'll see is an upstream API or SaaS endpoint changing in ways you didn't expect (or the difference between a Linux utility on the latest Ubuntu, an older RHEL, and Solaris), so it's often better to concentrate on testing the real thing.

And these tests are expensive, so an automated test matrix that deploys a VM fleet with lots of permutations is usually necessary.

Another magical thing (that I'm yet to try myself) is automated testing against live system. This ensures that the system actually works in production, not just on staging or test environment set up specifically for QA. I was initially against it, but reading about it recently[0] made me reconsider my opinion for some reason.

[0] Meditations by Sean Cassidy, http://blog.seancassidy.me/meditations.html

I too do systemsish programming in C++. All the places I've ever done this have "unit" tests that link in almost all of the executable and inject test data through the normal frontend. There's very little mocking; sometimes there will be a setFooForUnitTests() function to short-circuit some normal configuration path.