Dedicated to Ashley & Iris




НазваниеDedicated to Ashley & Iris
страница3/71
Дата24.09.2012
Размер3.51 Mb.
ТипДокументы
1   2   3   4   5   6   7   8   9   ...   71

Who Should Read this Book


Any engineer, using any platform and methodology, interested in a GUI’s success.

Teams creating modest or elaborate windows will learn a new development strategy. This book’s strategy upgrades your interactions with your colleagues, so they should also learn the new jargon and lifecycle. The strategy supports any methodology; this book illustrates the strategy working within Test-Driven Development and Extreme Programming.

This book pre-requires no other methodology book. Experience programming GUIs, using Object Oriented languages, is preferred.

This book is not a thin manifesto, but a hands-on experience. Begin to read by selecting one of several tracks through the material.

Developers


This book delivers a light, scalable strategy for “test-infecting” all kinds of GUIs. Part I reveals the strategy in platform-neutral terms. Sample code for each technique in the strategy appears in Part II: Case Studies. Each small project presents simple solutions for very hard GUI problems. Part III links the strategy to the “Agile” methodologies, and extends each Case Study with suggested Exercises.

If you are “the GUI guy”, this book will boost your velocity, and open new potentials. If you are not “the GUI guy”, this book will increase your reach into that realm.

You may need a technique whose code examples might not use your platform. All GUI platforms have common abilities, and all unit test frameworks in the SUnit, JUnit, NUnit family have common facilities. This book’s Case Studies create brief but powerful applications following the same strategy. It will work for you, no matter what your platform. The Case Studies use domains and environments as diverse as embedded software and the World Wide Web.

To get started quickly, read this entire Introduction, skim Part I, and read Chapter 2: The TFUI Principles. Then read either the most familiar Case Study, or the least familiar one. To “play along”, get the online source, decompress the archive matching the section that challenges you, install its few dependencies, and start testing and refactoring. Read a Case Study’s development session and enter each edit, or read Chapter 17: Exercises to think of a new feature to add. Then return to your own GUI project, to write tests with the extra features this book recommends.

If you use a published GUI test rig (such as Abbot, AutoRunner, Cactus, Canoe, Jemmy, JfcUnit, HtmlUnit, HttpUnit, NUnitASP, Rational Visual Test, Samie, Selenium, SilkTest, Struts­Test­Case, Test­Partner, Watir, WinRunner, etc.), lead it to support the techniques recommended here. Some come very close, so this book need not dwell on all of them. They cover gaps in GUI libraries; this book focuses on the gaps themselves. Some GUI test rigs provide new gaps.

If you have no pre-existing GUI test rig, follow this book’s techniques to rapidly create a minimal and proactive one tuned to your project’s topology.

TODO gloss for TFP and TDD; check that TFP never means TDD

If Test-First Programming (TFP) already drives your GUI, skip directly to the Principles Temporary Visual Inspection (page 19) and Temporary Interactive Test (page 19).

If a Case Study uses a GUI platform that you are learning, this book supplements its tutorials and references. It recommends you ask questions that they might not answer, so you will also become familiar with your platform’s online communities!

Journey through this book with or without the company of any of the fine Agile books that cover the general theories and/or your specific platform. If you don’t have one (yet), Chapter 16: Test-First Programming explains the TFP lifecycle, and Chapter 2: The TFUI Principles adds GUI enhancements. Chapter 5: SVG Canvas and Chapter 6: Family Tree illustrate test-first and refactoring in detail, producing a brief yet powerful project. These Chapters use a simple and portable GUI platform that rapidly enables these techniques. If you play along, you will soon forget that you are testing-first a GUI.

Your own project, platform, and test rig might not enable these techniques so rapidly. Hence the rest of the book.

Students


Those who have not yet read any other methodology book should read Part III first. It introduces the “Agile” and design topics that other Parts assume you know. As that Part raises question about general software engineering, follow its citations out to the relevant books. These are listed in the Bibliography on page 498.

Testers


An Agile project begins when testers convert business requirements into technical specifications that can be tested. This book demonstrates one of several Acceptance Test Frameworks that host these specifications as literate tables of data, and execute them against live code.

This book teaches your developers to use Test-First Programming to implement the features that then pass those acceptance tests. TFP produces a clean design and robust code, with many low-level test cases as a by-product. TFP does not produce industrial-strength tests (and bookstores should not shelve this or other Test-Driven Development books with the “Testing” or “Quality Assurance” books). Agile projects need testers to add the real tests that attack code with twisted scenarios to find its boundaries, and collect metrics to rate its health.

You will have time to do all that, because TFP rapidly produces decoupled code that resists bugs. You will find new tests very easy to add, and defects very easy to characterize. Long hunts for the sources of bugs will become very unlikely.

Read this entire Introduction, Chapter 13: Agility, Chapter 16: Test-First Programming, and Part I. Then skim Part II to find “attacks” suitable to your situation.

Usability Experts


No automated test can judge usability. This book presents only a trace of GUI design theory. Yet this book will change how you specify, design, and review GUIs.

This book helps teams keep GUIs flexible, robust, and visible, permitting aggressive upgrades, automated tests of usability details, and multiple “skins” for diverse user populations.

Read Chapter 4: The Development Lifecycle with GUIs, and the second half of Chapter 9: Broadband Feedback.

Leaders


Without Agile practices, software engineering projects occupy a spectrum, from excess paperwork to undisciplined hacking. GUI implementation trends toward the hacking end, lead by vendors’ tools that make GUI prototyping appear as easy as painting. Their tools irresistibly link painting and coding to code-generating wizards and full-featured debuggers. They neglect hooks to enable testing. These biases resemble old-fashioned manufacturing methodologies that planned to over-produce hardware parts, then measured them all and threw away the defects. Both speculative planning and endless hacking risk extra rework and debugging, as fixing old bugs causes new bugs.

Agile projects rise above that spectrum. We apply discipline to the good parts of planning and hacking. We carefully plan to write many tests, until new features are as easy as hacking—without the low design quality, high bug rate, and inevitable decay. Agile projects become useful early, add value incrementally, and maintain their value.

Most “Agile” books compare Agility to methodologies that analyze requirements and plan designs in big batches before implementing them. This one compares it to our distinguished heritage of hacking and debugging GUIs.

Use this book along with any of the fine Agile resources on the market—in print and in person—to adjust your teams’ behaviors, and upgrade their results. Read this entire Introduction, Part III, and Chapter 4. Help your crew experiment and play with their GUI libraries, to introduce Chapter 2’s technical recommendations. This brief investment will reinforce your new process, and pay your project back many times. An ounce of prevention is always better than a pound of cure.

This book recommends extra research into corners of GUI architecture that might be a little dark. It shows programmers how to convert that research into extra code that makes tests easy to write. The goal is rapid, scalable, and sustainable development, without more excessive research. Expect to see this progress; it will appear quite different from the usual GUI hack-n-slash.
1   2   3   4   5   6   7   8   9   ...   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

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


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