#679 Add tests for vertical scaling

[AndreaPuffo]

Closes #679. It does not contain the FIFO robot example (we will need to discuss #709 in order to add it).

[dhendriks]

I only had a quick look. Busy today.

[dhendriks]

Suggested change

	/**
	* Regression tests.
	*/
	/** Regression tests. */

Here, but also in the other class for non-vertical scaling tests.

[dhendriks]

I didn't check the tests in full detail. Did you look at what we changed in all pull requests for vertical scaling, where we added new code, and whether these new tests cover all new code/cases, reasonably? Or, phrased in another way: why did you add these tests, specifically, and not others/more?

[dhendriks]

This one has no 'images' folder.

[AndreaPuffo]

Some synchronization issue with Eclipse, I suppose.

[AndreaPuffo]

why did you add these tests, specifically, and not others/more?

• bitflipper: this is the vertical scaling version of the bitflipper example that is used in the documentation, and contains synthesis and usage preconditions. Simple test, it checks for synthesis/usage preconditions.
• concrete_all_elements: the to-be-synthesized activity must call a concrete activity that contains all the UML elements that we support (opaque actions, shadowed and non-shadowed call behaviors, some atomic/deterministic, some non-atomic/deterministic). It tests all the supported UML elements.
• guards_not_added: contains a concrete activity with a non-deterministic opaque action that makes a boolean variable true or false, and a loop. This example is related to the next one (postconditions for guard computation). The concrete activity contain an opaque action that may turn a boolean variable to "true", and then a decision: one outgoing edge towards the final node with guard "value=true", and one outgoing edge back to the opaque action with "true" guard. In practice, the activity can flip the value of the variable even if its value is already "true". We synthesize an activity that aims at making the variable "true" by calling the concrete activity. It is important to notice that guard computation does not add guards to the aforementioned outgoing edge with "true" guard, due to the disable-event requirements. Once we achieve the to-be-synthesized activity postcondition, we let the concrete activity finish, hence synthesis does not add any guard to that outgoing edge. It tests the behavior of guard computation in a counterintuitive (imho) situation, and it is couple with the next test.
• need_for_two_postconditions_guard_computation: contains a concrete activity with a non-deterministic opaque action that makes a boolean variable true or false (crucially, does not contain the loop back as the previous example). We synthesize an activity that aims at making the variable "true" by calling the concrete activity. In this case, the synthesized activity contains a decision node after the concrete activity with two outgoing edges: one goes towards the final node, with guard "variable=true"; the other edge goes back to the beginning of the concrete activity, with guard "variable=false". In this case guard computation adds these guards because the concrete activity contains only the final node after the value flipping, and hence the disable-events prevent the activity execution from going back. It tests the behavior of guard computation in a counterintuitive (imho) situation, and it is coupled with the previous test.
• nested5calls: contains 5 boolean values and 5 abstract activities. The first activity must turn the first boolean "true" by calling an opaque behavior. The second activity must turn the first and second boolean "true" by calling an opaque behavior and the first synthesized activity, and so on for 5 times. It tests horizontal and vertical scaling with simple nested activities.
• simple_decision: contains two identical concrete activities. The abstract activity can call either of them; to fulfill the activity postconditions, just calling one of them would be fine. Furthermore, the concrete activities have an impossible branch (see also the following tests). The synthesized activity calls both activities in parallel (max permissiveness). It tests maximally permissiveness, guard computation behavior with disable-events (similar to the previous tests) and simplifications with impossible branching (see also following tests).
• simple_decision_false_branch: contains a concrete activity with a branch whose guard is "false". The synthesized activity does not contain this branch at all (it disappears during the state space generation). It shows modifications to the concrete activities during the synthesis chain.
• simple_decision_impossible_branch: contains a concrete activity with a branch that cannot be taken (its guard is not p1 while variable p1 is default as "true"). The synthesized activity does not contain this branch at all (it disappears during the state space generation). Slight modification of the previous test.

[AndreaPuffo]

why did you add these tests, specifically, and not others/more?

More test can always be added. These are simple and/or the ones that gave us some issues recently. More could be added, for instance regarding simplifications of the control nodes/flows (step 17 of the current synthesis chain), although this issue is more esthetic than functional. Looking at the list in #379, all those items are covered in one or more tests.

If you come up with additional things to test, please let me know and I'll add them.

[AndreaPuffo]

Ready for review.

[dhendriks]

Do we have a test that synthesizes a higher-level activity that calls some lower-level ones in parallel?

[AndreaPuffo]

Do we have a test that synthesizes a higher-level activity that calls some lower-level ones in parallel?

Added a test for it, called simple_parallel. I've also updated simple_decision to include a decision between two lower-level activities. Ready for review.