Bridges and Tests

Last Friday, a lorry hit a railway bridge and I thought I wasn't going to get home (the bridge was between work and home). This is because they had to get a structural engineer to go and check the integrity of the bridge before they could let anymore trains go over it.
Bridges have been around for a long time, and the tools and techniques to test their integrity are well established.
Fortunately, the bridge was fine, and I got home around the normal time.
However, I thought this might may a good analogy for why it is important to create automated tests for your code (I'd prefer unit tests and integration tests, but other forms of testing are equally valid).
Consider your code as being the bridge.
The trains are analogous to the data that your code processes.
The tools and techniques used by the structural engineer are the tests (hopefully automated) that your code has to passed before being released.
And the lorry? Well, that's a change in the code, such as an additional feature, or a refactoring, or maybe even a bug fix.
So, the question is, after the lorry hits the bridge, would you be prepared to let the trains continue to run before you'd thoroughly tested it for integrity?
Or, in coding terms, after you've changed your code, should you be prepared to let your it process data before it's been thoroughly tested?
If you have automated, up-to-date tests in place, you can easily test your code (bridge?), and get the trains running (data processing) going as soon as possible.
Without them? Well, it's a long hard night in front of the monitor for you and your testing team*.

*In most places I've work, the coders are the testers, so it looks like another, long, lonely night at work for you.