Class AnnotationsUsageCountCacheTest
java.lang.Object
org.glassfish.jersey.test.JerseyTest
ubic.gemma.rest.util.BaseJerseyTest5
ubic.gemma.rest.AnnotationsUsageCountCacheTest
- All Implemented Interfaces:
org.springframework.beans.factory.Aware, org.springframework.context.ApplicationContextAware
@ContextConfiguration
@TestExecutionListeners(value=org.springframework.security.test.context.support.WithSecurityContextTestExecutionListener.class,
mergeMode=MERGE_WITH_DEFAULTS)
public class AnnotationsUsageCountCacheTest
extends BaseJerseyTest5
The per-URI corpus usage-count cache behind
/annotations/search?rank=composite.
These live in their own class because the sibling AnnotationsWebServiceTest context
deliberately wires no CacheManager, which disables every cache in the endpoint. That is
the right default there — it keeps those tests measuring the endpoint rather than a cache — but
it also means the caching path ships untested unless something opts in, which is what this does.
What is worth pinning is not that a cache exists but that it is keyed per URI. A typeahead sends a new query on nearly every keystroke and each one proposes a candidate set overlapping the last; keyed per result set, every keystroke would miss and the cache would buy nothing.
-
Nested Class Summary
Nested Classes -
Constructor Summary
Constructors -
Method Summary
Modifier and TypeMethodDescriptionvoidvoidA URI nothing uses is the common case in a broad candidate set, and it is the one a naive cache drops: with only non-zero counts stored, every uninformative candidate goes back to the database on the next keystroke, which is most of them.voidThe tally is ACL-restricted, so an entry computed for one reader must not be reachable by another.voidThe point of the cache: a keystroke that re-proposes a URI already counted must not send that URI back to the database.Methods inherited from class BaseJerseyTest5
configure, configureClient, getTestContainerFactory, setApplicationContext, setUp, tearDownMethods inherited from class org.glassfish.jersey.test.JerseyTest
client, close, closeIfNotNull, configureDeployment, disable, enable, forceDisable, forceEnable, forceSet, getAsyncTimeoutMultiplier, getBaseUri, getClient, getLastLoggedRecord, getLoggedRecords, getPort, getSslContext, getSslParameters, isEnabled, set, set, setClient, target, target
-
Constructor Details
-
AnnotationsUsageCountCacheTest
public AnnotationsUsageCountCacheTest()
-
-
Method Details
-
clearCache
@BeforeEach public void clearCache() -
testOnlyTheNewlyProposedUriReachesTheDatabase
@Test @WithMockUser(username="curator") public void testOnlyTheNewlyProposedUriReachesTheDatabase() throws SearchException, TimeoutExceptionThe point of the cache: a keystroke that re-proposes a URI already counted must not send that URI back to the database. Only the newly-proposed one does.- Throws:
SearchExceptionTimeoutException
-
testAUriNothingUsesIsCachedToo
@Test @WithMockUser(username="curator") public void testAUriNothingUsesIsCachedToo() throws SearchException, TimeoutExceptionA URI nothing uses is the common case in a broad candidate set, and it is the one a naive cache drops: with only non-zero counts stored, every uninformative candidate goes back to the database on the next keystroke, which is most of them.- Throws:
SearchExceptionTimeoutException
-
testCacheEntriesAreScopedToTheReader
@Test @WithMockUser(username="curator") public void testCacheEntriesAreScopedToTheReader() throws SearchException, TimeoutExceptionThe tally is ACL-restricted, so an entry computed for one reader must not be reachable by another. Asserting on the key rather than on a second request's result because the alternative — driving the same endpoint under two security contexts and watching for a wrong number — only fails if the counts happen to differ, and would pass silently the day they match.- Throws:
SearchExceptionTimeoutException
-