Policed and unpoliced limits

Rate limits are usually unpoliced – if you go over the specified rate, the application will do its best to service requests or perform the requested action. As we saw in Chapter 7, Testing of Error Cases, there are also policed limits, such as the number of configured users, which are designed to reject requests after a specified limit.

That might be a configured number of some entity, the maximum simultaneous connections, or the maximum number of operations your system can perform in parallel. Whatever the limits are in your system, identify them all and test what happens when you go beyond them. These tests are designed to fail, so the only question is, does the application fail gracefully, letting users know why their request can’t succeed?

You can also stress test these limits, repeatedly attempting to add more entities or connections beyond the maximum to ensure that an attack of that kind can’t degrade your system. This...