5 Reasons why you should Hand Code Coded UI tests
There are many ways to approach the test automation in Coded UI and it is highly important to develop an overall approach which suits your project. If you approach automation purely from a Record and Playback perspective, you are due for a big surprise later on. In a Record and Playback approach, tests are performed manually while the inputs and outputs are recorded in the background. During a subsequent execution, same steps are played back with the same input values and the actual outputs are compared with the stored ones. Any differences are reported as errors.
Although the Record and Playback approach in Coded UI will get you on-board with a very little learning curve, there are several disadvantages in using this approach. Here are the 5 reasons why we should hand code the Coded UI tests:
- Recording produces scripts that are difficult to maintain. Amending a recorded script and getting it to replay correctly requires a lot of time and effort. Moreover, as the application’s functionality grows, the more tests you record. You will have to re-record scripts due to functionality changes e.g. screens/objects added, modified or removed. Maintenance of these recorded scripts will become an immense burden at some point costing you even more time and money. Maintenance is very important in test automation and this in fact, is one of the main motivation factors to build a robust Automation Framework using the hand coding approach.
- Record and Playback scripts hardly take advantage of code re-use from one test to another. The hand coding approach, on the other hand, would facilitate code organisation, minimise duplication and makes it easier to re-use the existing code. Moreover, with the hand coding approach you can provide meaningful names to the objects instead of auto-generated names which were given to them at the time of recording the script.
- With a basic Record and Playback Coded UI script, if something unexpected happens during test execution, the test will fail. A hand coded Coded UI test however, can be programmed to cope with different events that may happen and not just “what happened” when the script was recorded.
- The Application Under Test must be stable enough for business transactions to be recorded, leaving very little opportunity for early detection of errors. On the other hand, if you are using a Hand Coding approach, you can start coding your object repository, business logic, utility functions and test scripts early in the project. You would have already finished majority of the ground work when the first build becomes available to test!
- For large applications, test execution performance may decrease due to duplication of objects and hence resulting in a very large object repository. This is because the same object may be recorded multiple times in different scripts. With the hand coding approach you can have a single repository which is used by all the tests.
The 5 reasons listed above, in my view, should establish a strong case for Hand Coding your Coded UI tests.