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 a base class for unit tests, called SensitivityMeasureTestBase
. Extending this class allows a unit test to wire all non-replaceable beans and beans that can be replaced via qualified @Primary
custom beans. A CubeTester
object is provided within the class, directly accessible in any extending class.
A test extending this class will only require store, reference, measure chain, and dimension configuration to be imported, alongside any beans required by the calculations. Data shall be provided as a separate Spring Bean
, and individual @Test
methods can run queries against the provided tester
object.
A sample test using this configuration is provided. The following is the test class definition:
@SpringJUnitConfig(classes = {
// Datastores
FxRateStoreConfig.class,
MarketDataSetStoreConfig.class,
TradeSensitivitiesStoreConfig.class,
MarketDataStoreConfig.class,
SensiLaddersStoreConfig.class,
CorporateActionStoreConfig.class,
DynamicTenorsStoreConfig.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,
// Data
DeltaPnLExplainScalarPostProcessorTest.TestConfig.class
})
@TestPropertySource(properties = {
"mr.enable.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. To couple the data with the test using it, we recommend static inner classes:
public static class TestConfig {
@Bean
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. Other replacement beans can be provided within the static inner class.
Queries can then be run using the CubeTester API through the tester
object:
@Test
void testDeltaLadderPnLExplain() {
tester
.mdxQuery("SELECT NON EMPTY { [Measures].[Delta PnL Explain] } ON COLUMNS, NON EMPTY Risk Factors.[RiskFactor].Members ON ROWS FROM ( SELECT 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");
}