No realistic amount of testing would have caught this weakness. It's how the community handled this situation that proves how strong it is.
A test case with a maximum size blocks made up of minimum size transactions would have caught this. We certainly need a test case like that going forward, especially if we are going to raise the block size limit.
It's not that simple. If I recall correct, it was about using a huge number of inputs in a certain pattern, not the overall size, not the overall number of transactions. Plus it shows up only on some BerkelyDB library versions.
Bottom line is: any automated feature-based unit and integration testing is necessarily focussed on
how the developer intends things to be, and thus will never be able to catch all the cases which arise from connecting things in unexpected and never intended ways.
Thus, well it is a good idea to increase the unit and integration test coverage, which is (as I understand it) rather just "average level" for the reference implementation. However, improving, developing and rehearsing mechanisms of crisis reaction is similarly important, if not even more important than test coverage. Since we will certainly encounter all the really interesting defects in real world usage, not in the testbed.
