Testing
This section explains how to set up and run integration tests for bookmarks, provides samples for custom integration tests, and outlines unit tests.
There are a number of unit and integration tests across the project in each of the modules.
Integration Tests
By default, the integration tests will not get executed when you build the project, as they have a severe impact on build time.
There is a separate Maven profile called IT
that you can run with the
following command when you want to execute the integration tests:
mvn install -P IT
.
Bookmark Tests
The application uses a test harness library which has been developed to regression test Atoti Server projects. This library enables us to start up a cube, execute MDX queries and assert the values match.
By default, the Atoti Server instance will load data from /src/test/resources/data.
Creating Bookmark (MDX) Tests
-
Start up your Atoti Server instance.
-
Run the class
com.activeviam.mr.regression.bookmark.creator.BookmarkTestCreatorRunner
- This will create a set of files in the folder with MDX queries in /src/test/resources/test-bookmarks. All the MDX queries will be stored in files ending with .query. -
Stop your Atoti Server instance.
Creating/Replacing Expected Results
Run the class com.activeviam.mr.regression.ReferenceRegressionTestIT
as a
Java application - This will start up an Atoti Server instance, execute
the queries in /src/test/resources/test-bookmarks and store the
results in files ending with .csv.
Executing Bookmark (MDX) Tests
Run the class com.activeviam.mr.regression.ReferenceRegressionTestIT
as a
JUnit test - This will start up an Atoti Server instance, execute the
queries in the files ending with .query and assert the results against
the corresponding file ending with .csv.
Custom Integration Tests
Integration tests can be defined fully in code, this includes things such as sample data being injected into the Atoti Server instance, the query being executed together with the expected values.
There are a number of sample integration tests in the reference implementation that have been defined as examples.
Example implementations of this class can be found in the reference implementation.
Unit Tests
By default, unit tests are executed when you run mvn install
. Some
example tests can be found in the MR application module, where
datastores have been created and mocked in order to test certain
functionalities.
Sensitivity module measure testing
The sensitivity module provides an abstract base class for unit tests, called SensiMeasureTestConfig
. Extending this class allows a unit test to wire all non-replaceable beans and beans that can be replaced via qualified @Primary
custom beans. Postprocessor injections are handled in a @BeforeEach
method, a Cube tested object is created and an abstract data()
method is provided.
A test extending this class will only require store, reference, and measure chain, and dimension configuration to be imported, alongside any beans required by the calculations. The overridden data()
method will supply the required data to the Cube, and individual @Test
methods can run queries against the provided context
object.
A sample test using this configuration is provided. The following is the test class definition:
@ContextConfiguration(classes = {
// Datastores
FxRate.class,
MarketDataSet.class,
TradeSensitivities.class,
MarketData.class,
SensiLadders.class,
CorporateAction.class,
DynamicTenors.class,
// Dimensions
DateDimensionConfig.class,
MarketDataDimensionConfig.class,
RiskDimensionConfig.class,
DynamicBucketingDimensionConfig.class,
CurrencyDimensionConfig.class,
SensitivitiesDimensionConfig.class,
BookingDimensionConfig.class,
// Measure parameters
BaseParametersConfig.class,
DeltaParametersConfig.class,
// Measure chains
BaseSensitivityChain.class,
BasePnLExplainChain.class,
DeltaNativeCurrencyChain.class,
DeltaLadderExpansionChain.class,
DeltaCurrentDateMarketDataChain.class,
DeltaPreviousDateMarketDataChain.class,
DeltaNextDateMarketDataChain.class,
DeltaPnLExplainChain.class,
// Formulas
PnLExplainFormulaProviderConfig.class
}, loader = AnnotationConfigContextLoader.class)
@Tag("Scalar")
@TestPropertySource(properties = {
"formula.rule.delta.commodity=Relative,1,1,true",
"formula.rule.delta.girr=Absolute,1,1,true",
"formula.rule.delta.csr-non-sec=Absolute,1,1,true",
"configuration.data-model.scalar-sensitivities=true"
})
class DeltaPnLExplainScalarPostProcessorTest extends SensiMeasureTestConfig {
}
Several stores, all references and most measure chains available in the application are excluded from this configuration, providing a minimal cube configuration that allows the calculation of Delta PnL Explain values.
Some of the imported dimensions contain levels or hierarchies that would be impossible to create without additional stores being imported, however the base configuration uses a DimensionFilter
object to ignore unbuildable dimensions.
As it is a scalar sensitivity test, the property is set to true, and PnL Explain formula properties are also set.
Data needs to be added to all stores impacting the tested calculations, using the SimpleTransactionBuilder
object:
@Override
public ITransactionsBuilder data() {
return SimpleTransactionBuilder.start()
.inStore("yourStoreName")
.add(tuple, with, all, correct, values)
.inStore("aDifferentStore")
.add(different, tuple)
.end()
}
All store additions defined in this test will be applied to the stores imported in the configuration.
Queries can then be run using the CubeTester API through the getContext()
method:
@Test
void testDeltaLadderPnLExplain() {
getContext()
.mdxQuery("SELECT NON EMPTY { [Measures].[Delta PnL Explain] } ON COLUMNS, NON EMPTY [Risk].[Risk Factors].[RiskFactor].Members ON ROWS FROM ( SELECT [Risk].[Risk Factors].[ALL].[AllMember].[BRL.OIS_Implied yield] ON COLUMNS FROM [Sensitivity Cube])WHERE [Dates].[Date].[AsOfDate].[2018-09-20]")
.getTester()
.hasOnlyOneCell()
.containingFormattedValue("17,576,250.00");
}