One colleague encountered My Lead OPA test faiulre on test case “Add Product test”:

Error context

The main steps involved in this test faiulre:
Add button is clicked, Product list dialog appears
Product list dialog is closed by oFragment.close();
Add button is clicked again. Product list dialog is expected to open for the second time
Product “Basic service outdoor” is searched against the opened product dialog - failed!

Analysis

The root cause of failure in step4 is, the expected product list dialog is NOT opened in step3. When open function is called, it is returned early in line 415, as a result Dialog is not opened at all. The UI5 framework considered this popup instance is still in status OPENED.

In order to find out why popup instance has status OPENED, we have to check the previous step when this instance is intended to be closed. The close call only sets status as CLOSING.

The real close operation is wrapped in another callback fnClose with time delay 210 milliseconds. There will be a fade out animation implemented by jQuery and the status from CLOSING to CLOSED is only set at the end of this animation. So when the add button is clicked for the second time, this scheduled call is not triggered yet, so popup instance is not decided to open by UI5 framework.

There are four solutions to make OPA test pass.

solution 1

In original implementation, the dialog instance behaves as a singleton. The same instance is shared during multiple Add button press. If every time a new dialog instance is created, the previous status set by open or close will NOT have impact on the next button press, so this issue could be avoided.
Code change:

drawback

productive code must be changed, a slight overhead due to dialog instance initialization every time Add button is clicked.

solution 2

Since the real close operation is delayed to execute 210 milliseconds later, in Lead productive code, if we manually changes some internal flag of dialog status, such as bOpen and eOpenState on behalf of UI5 framework, the subsequent call of open() will succeed as expected.

drawback

UI5 will never expect those internal flag to be changed by application. Any application code with manipulation on those internal logic becomes fragile and will easily be broken on every UI5 version upgrade.

solution 3

When debugging the close implementation of dialog, we are aware of the fact that there is alternative of dialog close without any animation.

Based on this finding, we can use the API setDurations and pass 0 as parameter for closing animation.
See line 1207 in above screenshot, in this case fnClosed will immediately be executed, which can resolve the timing issue.

drawback

Now our UI behavior is changed due to this change. The dialog disappears from UI immediately after cancel button is clicked. Not so good user experience compared with default 210 animation effect. Compare the difference by the following two videos:
0 delay.zip
210 delay.zip

solution 4

Delay the second Add button press untill the previous close operation completely finishes with all animation done. This could be achieved by scheduling the original press call in a wrapper with setTimeout and a delay > 210 milliseconds.

Although all four solutions can work, however this solution 4 should be used as it only contains OPA code change and no impect on functionality & UX on our application.