Knockout binding doesn't work

Hello Alexander,

I hosted a local application with the your code and recorded a sample Web test in Test Studio. My test is designed to enter text in that field without SimulateRealTyping enabled and I was able to execute it without any troubles. That said, I only have a small code snippet and not the full application.

I would expect to see a successful test with SimulateRealTyping on your end, as this replicates the real user behavior. This leads me to believe that the misbehavior is specific to the application under test and I will need your help to investigate it further. Please share more details, like:

- a archived sample Test Studio project that you recorded against the application and reproduces the issue;
- the exported step failure details or execution log, depending if the test fails or not;
- temporary access to the application under test, so I can execute the above project and troubleshoot it directly.

I am looking forward to hearing from your and continue investigating this misbehavior. I hope to help you find a solution quickly.

Regards,
Plamen Mitrev
Progress Telerik

Hi Plamen,

I've attached my project and execution log.  

And when you manually type in value in Policy Number input, you can see it in console viewModel.PolicyNumber._latestValue

This is not happening when TestStudio does it. :(

Hi Alexander,

Thank you for sharing a sample project and log. That helped me get a better overview of the test and explore the configuration in more details.

I noticed that the application under test has a static header, which is always visible in the browser. As a results some of the fields are hidden behind the header and the simulated real typing action does not happen properly. For example, if you enable SimulateRealTyping on all steps that enter text and turn on the annotations, you will see that the browser scrolls down and the target element is behind the page header. This prevents Test Studio from clicking on the actual field under it and then entering the text.

You can actually change the way the browser is scrolled and where the target element will be positioned. In this case, I would suggest that you change the ScrollToVisibleType option to ElementBottomAtWindowBottom in the Properties pane. You need to do that for all test steps that require SimulateRealClick and SimulateRealTyping.

The simulated real user behavior should trigger all events on the page the same way as a real used does, while using the application through the browser. Once the steps are configured to scroll the right way, you should see the values populated properly. I did a full test run on my end and I believe that it was successful.

Please try the above suggestion and do not hesitate to contact us again, if you need any help.

Regards,
Plamen Mitrev
Progress Telerik

Hi Alexander,

I am happy to know that the test now executes successfully and reliably.

If there is anything else that concerns you, please don't hesitate to contact us again.

Regards,
Plamen Mitrev
Progress Telerik

Hi Alexander,

It seems to me that this could be a timing issue, so you can try to execute the same test with the annotations turned on. That will automatically insert a 400ms delay by default between each action and will annotate it in your test. It also makes it easier to troubleshoot the test steps during execution and you can see which actions are executed.

In case the above suggestion helps with the test execution, you can add a wait step or execution delay whenever it is needed. A good rule for that is to add such wait steps or delays when the page is reloaded/redirected or the content changes.

If you continue to experience some troubles with the test execution, please share details, like:

- a sample Test Studio project that reproduce the misbehavior;
- which test steps are not executing as expected and what is the expected behavior?

I am looking forward to hearing from you.

Regards,
Plamen Mitrev
Progress Telerik

Hi Plamen

I have taken over the testing from Alex and I've changed the ScrollToVisibleType option to ElementBottomAtWindowBottom as you suggested and this helped. However, I have noticed that when the test is run on my second screen (extended display from my laptop), these typing fields are not populating again. I ran the same test multiple times yesterday and it worked on my laptop screen but then when I dragged the window over to my second screen it failed. Any ideas why this might be happening?

Sheridan

Hi Sheridan,

I am sorry to hear that the same test is failing on a different screen. I will share more details how SimulateRealTyping works and what could be causing the misbehavior. You will also find my suggestion to fix that issue and continue with the test automation.

The "Enter text" steps with enabled SimulateRealTyping actually perform a series of actions. Test Studio finds the target element, scrolls the browser to it, moves the mouse over that element and sends a mouse desktop click at that location. The final steps is to send keyboard actions and type the text 1 character at a time.

The most likely reason for the different behavior on the extended display is due to different scaling factor between the laptop screen and the extended display. As a result Test Studio does not move the mouse over the correct element and the next actions are not executed as expected.

Please make sure that both displays have the same scaling factor. It is recommended to use 100% on all displays that will be used to record or execute tests.

If you continue to experience some troubles with the test execution, please turn the annotations on and observe the execution. Let me know where the focus and mouse click actions happen on the screen and whether they are against the correct element.

I hope the above suggestion will help you resolve this issue. Please do not hesitate to contact us again, if you need further assistance.

Regards,
Plamen Mitrev
Progress Telerik