Dedicated to Ashley & Iris

НазваниеDedicated to Ashley & Iris
Размер3.51 Mb.
1   ...   4   5   6   7   8   9   10   11   ...   71

Chapter 2: The TFUI Principles

The last chapter defined “test-first”, where new tests force predictable improvements. This chapter describes the technical requirements that enforce test-first for GUIs, leading to a simple goal: You should be able to write new test cases that force your code to change a GUI’s appearance or behavior, without looking at or driving the GUI to confirm each change.

Wizards, form painters, and debuggers are useful tools. GUI Toolkit vendors promote their products by ensuring you can generate, paint, and debug a GUI until its appearances and behaviors stabilize. This directly contradicts our goal of heads-down development, without displaying a GUI, so tests can upgrade its appearance.

How to Test-Infect a GUI

We must make sure our lowly test cases can compete with our vendors’ offerings. We need to spend more time among our test cases than among our vendor’s tools, or our target application’s GUI. That requires giving test cases simple but useful GUIs of their own.

To get there efficiently, we will grow this GUI only by responding to real problems in our project. This chapter gives names to solutions for those problems, and shows how their solutions reinforce each other.

If you use an off-the-shelf GUI test rig, you can easily lead it towards this system. However, even the most limited GUI Toolkits can grow this system from their primitive components.

Tune your environment until you achieve each of these goals, in roughly this order.

TODO: please put these on one page, and put them inside the front cover

  • One Button Testing—the test rig takes care of all details

  • Just Another Library—treat GUI controls as objects

  • Regulate the Event Queue—learn how it works, then throttle it like a spigot

    • Temporary Visual Inspections—reveal a window in a tested state

    • Temporary Interactive Tests—drive it to spot-check responses

    • Broadband Feedback—abstract GUI review from manual interaction

  • Query Visual Appearances—assert what the window looks like

  • Simulate User Input—mock the user, and assert the window’s new state

  • Fault Navigation—tests, editors, and GUIs collaborate to illustrate faults

  • Flow—the goal is rapid, heads-down coding without displaying the GUI.

Those ideas need more explanations, and technical examples.

One Button Testing

To test, keep your hands on the keyboard or mouse, and tap one function key or click one button. The button invokes a test rig to save all changed files, compile, run selected tests, and report the results back, as fast as possible, and with no further interaction.

Your IDE might not do all those things. The sub-chapter Least Favorite Editor, on page 408, illustrates the kind of “glue code” an IDE might need to support an application written in multiple languages.

Do not, for example, write some tests in one test rig, and some in another, and launch these rigs from command lines at change time. Research how to get all their aspects into one build script, and bind it to your editor.

That principle generates all the other principles. They are all reactions to common reasons we might hesitate before testing, or perform any other interaction after testing.

Just Another Library

When you learn a GUI Toolkit by learning to use its form painter, you may begin to think in terms of “GUI on the outside, source code on the inside”. Event-oriented programming is not a good path towards event-driven programming.

To learn to take control of windows and forms “as objects”, we set a very simple goal:

During a test run, permit the fewest possible obnoxious side effects.
Run as many test cases as possible without displaying windows.

That’s just a goal; it’s not a Principle. The attempt to suppress all window Paint() events generates useful test code. Most windows keep their state in an internal object model, so they can quickly react to inputs before they slowly paint their displays. When you harness that effect, and query back your control’s internal state, your tests can run quick and quiet. And that, in turn, leads to less hesitation before hitting the One Test Button.

Some GUI Toolkits were designed to introduce programming, and they come with naïve conveniences that interfere with this principle. Some, for example, will throw an error if you attempt to perform trivial actions, like enabling a control or moving the focus while a window is hidden. Both those actions have memory representations; the GUI Toolkit needs no display hardware to accomplish them. Users would see the results the next time the window paints. Such bogus assertions might possibly help some junior programmers keep their windows visible.

Some GUI functions drive display hardware directly, and retain no impressions in memory. To test our code that invokes these graphic commands, we must first retain them. The research to treat the GUI Toolkit as a library will then support the research into its deviations.
1   ...   4   5   6   7   8   9   10   11   ...   71


Dedicated to Ashley & Iris iconDedicated to Ashley & Iris

Dedicated to Ashley & Iris iconAbramovitz, Janet N., and Ashley T. Mattoon. 1999

Dedicated to Ashley & Iris iconPlastics and the Environment. Hoboken. N. J. Wiley-Interscience. Ashley, S. 2002

Dedicated to Ashley & Iris iconGilliland home is dedicated

Dedicated to Ashley & Iris iconCitations Acknowledging or using iris-related facilities and Data As of August 2010 Please send corrections and/or additions to

Dedicated to Ashley & Iris iconDedicated to Jerry Lefcourt, Lawyer and Brother

Dedicated to Ashley & Iris iconFree to download magazine dedicated to Commodore computers

Dedicated to Ashley & Iris iconMorning session I: Dedicated to Prof. A. Acrivos, “Suspensions and particulates”

Dedicated to Ashley & Iris icon08: 30 Registration 09: 00 Welcome Remarks Morning session I: Dedicated to Prof. A. Acrivos, “Suspensions and particulates”

Dedicated to Ashley & Iris iconThe Culture of Irises in the United States Iris Culture for the Mountain and Plains Region, D. M. Andrews 5

Разместите кнопку на своём сайте:

База данных защищена авторским правом © 2014
обратиться к администрации
Главная страница