How is coded UI testing technique more favorable than any other testing technique? What is the main advantage of using a coded UI test?
The following are pros of UI testing:
- if you have no unit testing in place and no ability to introduce it (legacy code or external delivery), you can do testing
- good for integration and/or system level tests
- (up to a certain degree) mimick real user behavior/input
There are also many cons, mainly that they are more fragile, thus more difficult to maintain and create - I have found this to usually be true.
One more thing against them is that typically UI tests need a dedicated system (you need the UI and no other program running), unlike for unit tests where you could have 5 executing in parallel. This makes them impossible to run on a developer's machine before each check-in.
Then you have execution time, which makes it very hard to execute them on each check-in. In most scenarios UI tests are only executed nightly, weekly or even manually.
There's no one reason why teams use GUI tests as part of their integration or system testing programme, and no test type is best in all situations. A quick list of advantages based on an article by Alvin Alexander:
- Finding regression errors.
- Letting human GUI testers ("domain experts") get back to their normal jobs instead of running tests a robot should be running.
- Covering for application areas that don't have unit tests.
- Detecting differences in behaviour between platforms
Where I've used GUI testing most extensively was when we had to support a complex GUI across a large matrix of systems. We had a Windows desktop app that had to run on XP, Vista, 7 and a couple of MS server OS's, with a few extras due to service packs. Since we interacted with Microsoft office those variations were multiplied by the Office versions we supported. So every release had to have a test script several hours long run on each of 20-odd combinations. That's just not feasible to do without an array of virtual machines and a GUI testing tool.
We recorded a number of sessions of real users, and had business analysts generate their own tests, plus the test team added their own. Even with regular pruning of the test scripts it took hours to run the full set.
Note that there are two broad categories of tools. "Universal" tools record mouse clicks/keystrokes and compare screenshots. "Inspection" tools interrogate the program under test to both find controls and read results. Many tools can do both, and some have libraries that you can build into your program to facilitate testing. Screenshot comparisons are always available but very fragile (in XP enabling keyboard language switching makes the taskbar one pixel higher, as an example of something that broke a whole series of our tests). But smart tools can trip up if controls are moved, renamed or the control type changes.
Consider the test pyramid In the top is UI. In the context of wpf with mvvm this means you unit test your model as much as possible. Then you unit test your view model as much as possible. This leaves a little bit of the UI untested and this is where coded ui test comes in. So a little bit of coded ui test would probably be a goood thing. If you use it too much you will test too much and the tests will be slow. Basicly just test that perperties are mapper properly to the view model.