Generators shouldn't visit SHARED vertexes without outgoing edges.

[Aleksandar Dinkov]

In my models I have many separate models with multiple shared points for moving between them. For example - it is possible to go back to the Home Screen from almost every model.

Here's how this looks.

• in Model1: [v_Home SHARED:Home] -----> [ SomeOtherScreen(s) ]
• in Model2: [Screen2] -----> [v_Home SHARED:Home]
• in Model3: [Screen3] -----> [v_Home SHARED:Home]
• in Model4: [Screen4] -----> [v_Home SHARED:Home]
• in Model5: [Screen5] -----> [v_Home SHARED:Home]

So. Imagine the model reaches Model2 and goes to v_Home.
There are no outgoing edges, so it can only go to another SHARED:Home.
It chooses the SHARED:Home of Model5 at random.
But once again, there are no outgoing edges.
It chooses the SHARED:Home of Model4 at random.
Once again, there are no outgoing edges.
....
And so on, until it hits the SHARED:Home of Model1

---

As a result of that, I get output that looks like this:

// This happens a lot and in many places in the test.
{"currentElementName":"e_someAction"}
{"currentElementName":"v_someScreen"}
{"currentElementName":"e_someOtherAction"}
{"currentElementName":"v_someOtherScreen"}
{"currentElementName":"e_clickBreadCrumbHome"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"v_Home"}
{"currentElementName":"e_click_tab_messages"}
{"currentElementName":"v_Messages"}
{"currentElementName":"v_Messages"}
{"currentElementName":"v_Messages"}
{"currentElementName":"v_Messages"}
{"currentElementName":"v_Messages"}
{"currentElementName":"v_Messages"}
{"currentElementName":"v_Messages"}
{"currentElementName":"v_Messages"}
{"currentElementName":"v_Messages"}
{"currentElementName":"v_Messages"}
{"currentElementName":"v_Messages"}
{"currentElementName":"e_openFirstMessage"}

Please optimize the node selection when selecting a SHARED node.
There is absolutely no point in selecting a SHARED node that doesn't have outgoing edges.

[Aleksandar Dinkov]

For now I will work around this by comparing the current step of the test with the last one.
If they are the same, I will simply skip that action and move on.

[Nils Olsson]

How are you running your tests? If you are using the @GraphWalker annotation you could specify your own PathGenerator that optimize this, and then we could add it to the repo if you would like to share the implementation.

A example can be found here https://github.com/GraphWalker/graphwalker-example/blob/961d9450180ac913536e8c3b0165cf960765da30/java-algorithm/src/main/java/com/company/MyTest.java

[Aleksandar Dinkov]

I am actually running C# tests.
In the beginning of the test I simply execute something like :

java -jar graphwalker offline -m model1 random(edge_coverage(5)) -m model2 ................. -m model10 random(edge_coverage(5)) > someTextFile.txt

Then I parse the text file and execute the test.
This way a test has about 500 steps.
(compared to thousands if the edge_coverage is even as high as 20)

But this seems to be different from what I actually want...
Is it possible to tell graphWalker that I want 5% coverage of ALL models (even if some models don't get visited at all), instead of 5% on EACH model (even if the total visited edges end up much more than 5%)

// But this is a separate question... I got sidetracked.

[Aleksandar Dinkov]

As for writing a specialized PathGenerator... It can be done, yes.
My Java is quite rusty, but writing something like this shouldn't be too hard.

But I believe that the default generators shouldn't behave like they do now.

It seems completely pointless to me to run the exact same verification 10 times in a row.
I cannot see any use case where that would make sense as a default behavior.

So... my suggestion is to simply remove these paths from the list of elements that generators can choose from.
Simply remove the option to go from a SHARED node to another SHARED node that is a dead end.

[Kristian Karl]

I believe this issue is [partly] fixed by #224 .
The fix was included in the latest release 4.2.0

The fix vill still visit the shared vertex with no out-edges. The way we designed shared models logic, a jump to another model using SHARED vertices is always valid.