|
There's layers to UI testing. There's going to be plenty of tests where you just want the UI to trigger your actions instead of testing the actions in isolation, and that's fine. In those cases, you want to seek out the accessibility API for the GUI framework and use that to perform the actions. "Accessibility" here is talking about augmentations you can make to your user experience to make the application accessible by people with disabilities. Treat your tests like use cases from a blind, deaf, quadriplegic. Coincidentally, the computer running the tests will be a blind, dead, quadriplegic. As a bonus, your application can not be used not only by a potential handful of blind/deaf people, but a larger group that tries to lean on those APIs when possible because their vision is particularly poo poo. GUI automation tools like AutoIt and Microsoft's UI Automation have all kinds of quirks in them. They're all extremely annoying. You want to avoid actual screen real estate commands ("click at 100, 350") and rather invoke on specific GUI components. Even with this, an unexpected dialog can tank the whole thing, or the command just kind of hangs, or doesn't register. You would treat these like integration tests with a separate test bench that kills that poo poo if it hangs up. Expect false failures. Somebody can call me out on those failures being false, but I've deal with plenty of off-the-shelf applications that will just glitch like that 1 in 1,000 times. On the other hand, you can tank that 1/1000 occurrence but you probably want your testing tool to warn on it and retry, only to error after X retries do the same thing. The machine on which you test should also be pretty clean so system popups and other junk don't get in the way. You can argue that this is not realistic testing, but the machine is focused exclusively on the UI, and you shore up the rest elsewhere. At some point, you're talking about testing as if a person is literally there with fingers and that's a whole other can of worms. You really only need to worry about this when you're making particularly custom controls. Even then, if they are plumbing into the GUI framework properly, those GUI automation frameworks that can invoke on controls should just take care of it. If all the tests using your control just vomit down the report, then you know the control died.
|
#
¿
Jan 15, 2021 20:57
|
|
|
|
| # ¿ May 10, 2024 13:29 |
|