Class CachedProcessedExpressionDataVectorServiceTest

java.lang.Object
ubic.gemma.core.util.test.BaseTest5
ubic.gemma.core.util.test.BaseDatabaseTest5
ubic.gemma.persistence.service.expression.bioAssayData.CachedProcessedExpressionDataVectorServiceTest
@ContextConfiguration @TestExecutionListeners(value=org.springframework.security.test.context.support.WithSecurityContextTestExecutionListener.class, mergeMode=MERGE_WITH_DEFAULTS) public class CachedProcessedExpressionDataVectorServiceTest extends BaseDatabaseTest5

  • Constructor Details

    • CachedProcessedExpressionDataVectorServiceTest

      public CachedProcessedExpressionDataVectorServiceTest()

  • Method Details

    • testGetVectors

      @Test @WithMockUser public void testGetVectors()

    • testGetVectorsForSubset

      @Test @WithMockUser public void testGetVectorsForSubset()

    • testGetVectorsForSubBioAssays

      @Test @WithMockUser public void testGetVectorsForSubBioAssays()
      This test exercise the ability of the service to retrieve vector for a subset of sub-bioassays.

    • testGetVectorsByProbeDoesNotLeakAnotherProbesCachedDataForTheSameGene

      @Test @WithMockUser public void testGetVectorsByProbeDoesNotLeakAnotherProbesCachedDataForTheSameGene()
      Regression for a cache-key granularity bug: two probes mapped to the same gene must each answer with their OWN vector, not whichever one happened to be cached first under that gene's key.

      Before the fix, caching cs0's vector by probe wrote it under the shared (ee, gene) key that testGetVectors()'s by-gene lookups also use; a later probe-scoped request for the different probe cs1 saw that key present and returned cs0's vector for it instead of fetching cs1's own. Found on real GEO data by RA (2026-09-30): /datasets/{id}/heatmap-data?probes=209072_at answered with 207323_s_at -- both probes of MBP.