ActivePivot testing strategy - testing

Question

I was thinking of implementing automated tests for different part of an ActivePivot Servers and most importantly post-processors.
Since I am at the very beginning, I would like to know more about the state of the art in this field, what are the best practices and if there are any caveats to avoid.
IF you have any experience, I will be delighted to read from you.
Cheers,
Pascal

Answer 1

That is a very broad question. An ActivePivot solution is a piece of java software and inherits from all the best practices regarding the testing and continuous build of a software project.
But here are some basic ActivePivot entry points:
How, where and when to write tests?
Write junit tests, run them with maven, setup continuous build with Jenkins.
How to embbed a (real, non trivial) ActivePivot instance within a unit test?
Start an embbeded Jetty web application server. The ActivePivot Sandbox application is an example of that (look at com.quartetfs.pivot.jettyserver.JettyServer). If you want a series of unit tests to run against the same ActivePivot instance, you can start the Jetty server statically (for instance in a static method annotated with #BeforeClass). In any case don't forget to stop it at the end of the tests.
How to write performance tests?
In the Sandbox project, there is a small MDX benchmark called com.quartetfs.pivot.client.MDXBenchmark. It is easy to enrich and a good starting point. There is also com.quartetfs.pivot.client.WebServiceClient that illustrates connecting to ActivePivot
How to test post processors?
As of ActivePivot release 4.3.5 there is no framework dedicated to isolated post processor testing. Post processors are tested through queries (MDX queries or GetAggregates queries). Of course if your post processor implementation has some utility methods, those can be tested one by one in standard unit tests.

Answer 2

To test an ActivePivot-based project, the simpler is to re-use your Spring configuration. This can be done with ClassPathXmlApplicationContext:
ApplicationContext context = new ClassPathXmlApplicationContext("beans.xml");
This simple test will check if your Spring is actually Ok. Then, if you want to run a query, you could do the following:
IQueriesService queriesService = context.getBean(IQueriesService.class);
queriesService.execute(new MDXQuery(someMDX));
If you want to check your loading layer, you can do:
IStoreUniverse storeUniverse = context.getBean(IStoreUniverse.class);
for (IRelationalStore store : storeUniverse.values) {
assertEquals(hardcodedValue1, store.getSize())
assertEquals(hardcodedValue2, store.search("someKey", "someValue").size())
}
This way, you don't need to start a web-app container, which may fail because it needs some port to be available (meaning for instance you can't run several tests at the same time).
Post-Processors should be either Basic or DynamicAggregation post-processors, which are easy to test: focus on .init and the evaluation methods called on point ILocations. Advanced Post-processors can not be reasonnably unit-tested. Then, I advice writing MDX queries as simple as possible but relevant given the Post-Processor.
Any unit-test framework and mock framework could be used. Still, I advice using JUnit and Mockito.

Answer 3

I would recommend using Spring4JUnit to launch the context. You can then autowire the beans and access things like the queries service and the active pivot manager directly.
#RunWith(SpringJUnit4ClassRunner.class)
#ContextConfiguration(locations = {"classpath:SPRING-INF/ActivePivot.xml", "classpath:cusomTestContext-test.xml"})
...
#Resource
private IActivePivotManager manager;
#Resource
private IQueriesService queriesService;
#Test
public void testManagerOk() {
assertNotNull(manager);
assertTrue(manager.getStatus().equals(State.STARTED));
}
#Test
public void testManagerOk() {
// run a query with the queries service
}
...
You can define custom test properties for the tests in a separate context file, say for loading a set of test data.