User Interface changes handling in Coded Ui Testing

What to do if your user interface changes ?

User interfaces frequently change during development. Here are some ways to reduce the effect of these changes:
  • Find the recorded method which references this control and use the Coded UI Test Builder to re-record the actions for this method. You can use the same name for the method to overwrite the existing actions. Do keep track that you record no multiple flows under single function module. Because that will bring lot of dependency of one module on other. For example you might be having the scenario of logging into Gmail and then clicking on the MyContacts link. One record action should be under one function module that is Login and the other event that is navigating to the MyContact link by clicking it.
    As a result of which what we shall be able to acheive is that even if tomorrow the Management decides to alter the MyContact link into some new name as MyRelatives , our script being specifically modularised into separate function name as in our case now is we can record just the Click event on the one control that is the new link for MyContacts that is MyRelatives. What comes out is that our script gets very modularised. And maintenance effort is minimised.


  • If a control has an assertion that is no longer valid:
    • Delete the method that contains the assertion.
    • Remove the call to this method from the test method.
    • Add a new assertion by dragging the cross-hair button onto the UI control, open the UI map, and add the new assertion.

      But this logic works successfully only in the case wherein we have just one assertion condition and this very function name can be hence re recorded and validated for our code maintenance ease.

0 comments:

Post a Comment