emoflon / emoflon-ibex-tests Goto Github PK

ClassInhHier2DB_MA gets stuck when initializing the democles engine (Bad Padding Exception deep in the democles code).

as this is a bit confusing as one expects the tests to be sync (but they are not necessarily).

I found out that the vis in the JUnit console can be improved if the following is used for parametrising JUnit tests:

@Parameters( name = "{0}" )

This displays for example the name of the BXTool (you have to update Benchmarx as I just implemented toString). As described here you can build a string that best describes your parameters: https://stackoverflow.com/questions/650894/changing-names-of-parameterized-tests

We should convert all metamodel projects to eMoflon projects, enable code generation for them, and get rid of all generated code and .genmodels.

and centralised in this single class for each TGG.

I have 3 errors currently in the test suite.

For some 0..* edges, no inverse edge can be created because the featureID is 0

Affected classes:

TestBlockDiagramCodeAdapter
TestProcessCodeAdapter
TestVHDLTGGCodeAdapter

When executing the performance tests for AlgorithmToStrategy_MA, CC and CO fail with an IndexOutOfBoundsException like this:

Caused by: java.lang.ArrayIndexOutOfBoundsException: -1
at java.util.ArrayList.elementData(Unknown Source)
at java.util.ArrayList.get(Unknown Source)
at org.emoflon.ibex.tgg.operational.strategies.cc.HandleDependencies.examineDependences(HandleDependencies.java:135)
at org.emoflon.ibex.tgg.operational.strategies.cc.HandleDependencies.examineDependences(HandleDependencies.java:125)
at org.emoflon.ibex.tgg.operational.strategies.cc.HandleDependencies.examineDependences(HandleDependencies.java:125)
at org.emoflon.ibex.tgg.operational.strategies.cc.HandleDependencies.lambda$5(HandleDependencies.java:115)
at java.util.HashMap$KeySpliterator.forEachRemaining(Unknown Source)
at java.util.stream.ReferencePipeline$Head.forEach(Unknown Source)
at org.emoflon.ibex.tgg.operational.strategies.cc.HandleDependencies.detectAllBundleCycles(HandleDependencies.java:114)
at org.emoflon.ibex.tgg.operational.strategies.cc.HandleDependencies.getCyclicDependenciesBetweenBundles(HandleDependencies.java:102)
at org.emoflon.ibex.tgg.operational.strategies.OPT.defineGurobiExclusions(OPT.java:245)
at org.emoflon.ibex.tgg.operational.strategies.OPT.chooseTGGRuleApplications(OPT.java:347)
at org.emoflon.ibex.tgg.operational.strategies.cc.CC.wrapUp(CC.java:192)
at org.emoflon.ibex.tgg.operational.strategies.OperationalStrategy.run(OperationalStrategy.java:318)
at testsuite.ibex.performance.run.PerformanceTest.timedExecution(PerformanceTest.java:41)
at testsuite.ibex.performance.run.PerformanceTest.lambda$1(PerformanceTest.java:72)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

At the moment some use platform:/plugin or other URIs which complicates the registration code a bit.

The TestSimpleNegative - testTwoDifSuperOneSubClassToDoc2 Unit Test fails non-deterministically.
The error message was that not valid solution could be found (I guess from the ILP solver and I used Gurobi)

Some of the test projects can not be compiled if the code generator is set to EMF (instead of SmartEMF):

• Algorithms
• Documents
• FamiliesWithSiblings
• TerraceHouses
• Strategies
• WoodenBlockSet

TODO: Set the Code Generator config in moflon.properties.xmi to SmartEMF and Enforced to true.

and make sure that all references in tests are to the centralised resources folders in our single test suite project.

The test testsuite.ibex.ClassInhHier2DB_MA.sync.AlternatingSync.testAddSuperAttributeDeleteColumn fails now and then with a strange NPE. Would be nice to understand why, and decide if the test is worth "reparing", indicates an actual bug in our implementation, or is simply non-deterministic and should be deleted.

http://bx-community.wikidot.com/examples:modeltests

We need some tests for a combination of CO and amalgamation.

Especially for the tests that take so long, we can now use the newly implemented reset function of the engine to avoid a new init (which is what takes forever).

Please see VHDL tests to see how to do this.

Correspondence model can contain several admins, while source and target model do not have one.
Admin generation only works when attribute condition is switched off.

The MODELGEN operationalization does not terminate within 2 minutes for 500 elements

/Testsuite/test/testsuite/ibex/MoDiscoIbexTGG/co/TestMoDiscoIbexTGG.java seems to be missing ILP solver configuration.

The test case fails in some executions: