OverviewGUIs are usually designed with a Model-View-Controller architecture in which the view is decoupled from the model. This separation presents a challenge to automated testing because it's difficult to verify that a state change in the model is reflected appropriately in the view—it spawns the Liar View bug pattern. We discuss how you can make sure both model and view get tested. Picture this: You've crafted a golden GUI program designed for a distributed system, all that your customer asked for and then some. You've run it through an extensive suite of automated unit tests. It came back with a clean bill of health. The pressure is on to deliver the GUI, but being the exacting programmer that you are, you fire it up for one last manual test only to discover erroneous behavior—behavior that should have been caught by the automated tests. If only you could have prevented this situation! Well, you can. Sometimes, despite passing its suite of tests, a program will, upon manual inspection, exhibit erroneous behavior that should have been discovered by one of the tests. Such behavior is common in distributed and multithreaded systems. In these cases, the nondeterministic nature of the program is often the cause. But in the case of GUIs, there is another common cause: the Liar View bug pattern. Here's the bug pattern in a nutshell:
|