Skip to main content

Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "VIATRA/Query/UserDocumentation/QueryTestFramework"

< VIATRA‎ | Query
(Added incremental scenario description)
Line 46: Line 46:
 
  with(snapshotAfterModification). // Any modify operation causes all previously loaded snapshots to be invalidated.
 
  with(snapshotAfterModification). // Any modify operation causes all previously loaded snapshots to be invalidated.
 
  assertEquals
 
  assertEquals
 +
 +
=== Supporting plain java objects in substitutions ===
 +
 +
In some cases plain java objects need to be added to the Query Snapshot model. However, the serialization and comparison of such elements might be relevant on the domain in which the testing framework is used. In this case, the framework allows the user to define how certain plain java types should be handled, through JavaObjectAccess elements.
 +
 +
//TODO

Revision as of 11:23, 14 March 2017

Query Test Framework

There is a test framework available specifically designed to test Viatra Queries. It was developed with the following use cases in mind:

  • Testing the Viatra Query Engine itself
  • Provide a regression testing framework for users to test patterns

Basic concepts

The framework allows the user to compare the results of a pattern execution using different engine implementation or to a predefined result set (so-called snapshot). It defines a convenient internal DSL to define test cases. A description of a test case consists of the following parts:

  • What to test
    • Generated query specifications
    • Pattern groups
    • Generic pattern groups (possible parsed directly from .vql files)
  • Input models
  • Execution methods
    • by Rete or LocalSearch engines
    • from snapshot
  • Assumption (optional)
    • Checks whether all given execution method supports the given patterns (i.e. the test case is applicable)
  • Assertion
    • Checks whether the results provided by all execution methods are the same for each patterns.

Example:

ViatraQueryTest. //Entry point
test(SomeQuerySpecification::instance).and(AnotherQuerySpecification). // Patterns under test
on(modelURI). // Load instance models (this may be optional if a snapshot model references the used input model)
with(snapshot). // Compare prepared results stored by a snapshot model
with(new ReteBackendFactory). // Compare results produced by the Rete engine
assumeInputs. // checks whether the given snapshots and backend factories are valid for the patterns under test. Throws JUnit assumption error otherwise
assertEquals // compute difference of each given snapshot and pattern executions. Throws JUnit assertion failure if differences occur

Incremental Scenarios

The framework supports testing scenarios in which the results can be checked again after a model modification using the modify method:

ViatraQueryTest. //Entry point
test(SomeQuerySpecification::instance).and(AnotherQuerySpecification). // Patterns under test
on(modelURI). // Load instance models (this may be optional if a snapshot model references the used input model)
with(snapshot). // Compare prepared results stored by a snapshot model
with(new ReteBackendFactory). // Compare results produced by the Rete engine
assertEqualsThen. // assertEqualsThen does not return void
modify(Type, [name=="John"], [age=35]). // The given operation is executed on each instance of the given type on which the given condition evaluates to true.
with(snapshotAfterModification). // Any modify operation causes all previously loaded snapshots to be invalidated.
assertEquals

Supporting plain java objects in substitutions

In some cases plain java objects need to be added to the Query Snapshot model. However, the serialization and comparison of such elements might be relevant on the domain in which the testing framework is used. In this case, the framework allows the user to define how certain plain java types should be handled, through JavaObjectAccess elements.

//TODO

Back to the top