We've been playing with the Caching Application Block here at the client I'm currently working with and have found a couple of important items that will be of interest to anyone doing the same. I should say that we're using NUnit to run our unit tests, so some of the information applies specifically to that.
Actually, both of the items we ran into had to do with the storage mechanism that we used. The Caching Application Block includes implementations for three separate modes: in process, memory-mapped files and SQL Server. These three modes basically mirror the functionality available with the Cache object in ASP.NET.
For all of the tests run to this point in the project, we had been using the in-process mode both in our unit tests and in the builds that have been sent to the system verification team. However we recently made the choice to share the caching across web services, so we switched to the memory-mapped file mode.
First off (and it should have been obvious), there is a different serialization technique used with memory-mapped files. That is to say, that the in-process cache doesn't use serialization at all. The memory-mapped version does serialize and deserialize the object as part of the default processing. This change in caching mechanism should have caused us to go back to our unit tests, updating the storage type used there. A couple of issues might very well have been exposed. But after just a couple of minutes of seeing unexpected errors occur in unusual places, we did just that.
If you didn't realize it, NUnit depends a great deal on the AppDomain model to work its magic. This allows things like the config file to be taken from the DLL's home directory. A completely new AppDomain is created for each run of the tests. So, as a for instance, you had created an in-process cache in one test, that cache wouldn't be there the next time the test was run. New AppDomain = new memory = no old variables.
But what if you were to change the storage mechanism to a memory mapped file. A mechanism that is specifically designed to share data across AppDomains. So now, NUnit does its AppDomain creation thing and pow! Cached value already exists. Imagine our surprise. Imagine how good you feel not having to go through it.
As a pointer, using the Flush method in the TestSetup section of NUnit is a good way to avoid this problem in the future. Just something for you to consider.