>That's a poor unit test. You should not rely on cached data for anything, and doing it this way is not unit testing, it's closer to integration testing. Each of those tests should set up the data in the way it needs, modify the data, test that the modification worked, and then destroy the data. If setup takes too long, rethink how you're doing it and what the method being tested is doing.
>
>Here's another book for your reading: The Art of Unit Testing
>
>Conditionally excluding tests is dangerous because there is a good probablity it will always be excluded.
>
The test itself does setup the data the way I want. My current problem is that our class uses cached table data and at the moment we do not yet have a method to refresh that cached copy on demand.

In other words, even if I update that preference table, the class will not see my update.