Testing security has traditionally been a challenge, because there are many facets to cover. Integrating with a 3rd party authentication system is one part that needs to be checked out. Making sure the application is using the security system is also needed. And confirming that both good and bad accounts are handled properly is important. Often, we tend to code successful scenarios. Its important to know that our software responds to failing scenarios as well. While this is important for general coding, it is especially critical to test failing security scenarios. If the system doesn't properly handle invalid or expired credentials, what is the point in securing the system?

By using the InMemoryUserDetailsService in an alternative application context, it is easy to create a whole host of user accounts that have all the permutations of roles, privileges, good and bad passwords needed to checkout the services. CherryPy is especially easy to test, because it doesn't require running the web container. Since CherryPy conveniently maps URLs to methods, it is easy enough to call the methods directly from a test harness rather than verify the web handling machinery of CherryPy. And swapping the data access layer with either stubs or mocks makes it easy to isolate business logic.

All these things help to build a high confidence automated test suite. With the core of our application easily subjected to automated testing, it now becomes easy to decide whether or not to use an automated web container test kit for the web layer. It is also an option to test the 3rd party security system through automated integration testing.

By removing the need to code security APIs by hand inside our business logic and also decoupling the web layer, it becomes much easier to automate testing, leading to a more powerful system that meets expectations.