Microsoft seems to be pushing making coded UI functional tests fault tolerant by using multiple methods of 'finding' controls on a page. If it can't find a control as its text has changed then it tries another approach. I recon it more likely to cause more problems that it would solve. At best it is unnecessary, and worst it will allow tests to pass when they should fail. Like over use of null reference guards in code that hide defects.
Microsoft's automation tools generate code that uses multiple approaches (fault tolerant) to find controls. I'm also seeing examples of this approach in VS2010 documentation/tutorials.
e.g: 4 minutes into: Introduction to Creating Coded UI Tests with Visual Studio 2010.
I do not understand the need nor the intent. On the 'need' level it implies that there is not a reliable method for finding a control although each control has a name or AutomationId that is independent of location, inner text, colour, visibility. On the intent level, if the control changes so you can not find it ... well ... I would rather the test failed.
I use test jigs and testers (thanks Nigel ... a pattern that should be documented) to access UI controls. Typically a page has a test jig and a property on the test jig provides access to control's tester or test jig. So, I have one place in which I define the control's id (e.g. AutomationId). So if it changes I just change one line.
Fault tolterant test code is an oxymoron.
Perhaps the next step is to make tests intermittent failure tolerant by retry on fail. :-)
1 comment:
It all comes down to testing first versus testing last.
If you were testing first, you'd never want automated tests to have 'wiggle room' like this.
Post a Comment