If you want to test the published API and the cache is "hidden away", i.e. you cannot check through the API whether or not the cache "worked", there is no good way to test it.
But nothing of course stops you from checking the internals of your modules in a different set of tests.
I have had a similar problem, where I had written a framework into which a specific parser was to be plugged-in. The framework contains its own set of basic "utility" methods, some of which are used by a parer-plugins. One set of tests exercise the "utility" methods (which is the low-level internal API) and the tests linked to the parser plugins test whether the frame-work including the parser "works as advertised" by using the external API.
Applying this to your case, I would say test both the API (for which the cache is not an issue) and also test the working of the cache itself by stepping inside of your API.
CountZero
A program should be light and agile, its subroutines connected like a string of pearls. The spirit and intent of the program should be retained throughout. There should be neither too little or too much, neither needless loops nor useless variables, neither lack of structure nor overwhelming rigidity." - The Tao of Programming, 4.1 - Geoffrey James
In reply to Re: Testing objects that cache
by CountZero
in thread Testing objects that cache
by dreadpiratepeter
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |