Dedicated to Ashley & Iris




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

Style


Read this—it’s not the usual “yadda yadda yadda”.


  • The word Pattern as a Proper Noun cites either the book Design Patterns, by Gamma, Johnson, Helm, & Vlissides, or Smalltalk Best Practice Patterns by Kent Beck. Common pattern-like things without a “Pattern Language” deserve only a lower-case “pattern”.




  • Likewise, Refactor as a Proper Noun cites the book Refactoring. It means changing a program’s structure while leaving its behavior the same.




  • An “AntiPattern” is a common software engineer behavior that inhibits productivity. Our industry depends on far too many AntiPatterns for every use of the word “AntiPattern” to cite the book AntiPatterns: refactoring software, architectures, and projects in crisis by Brown, Malveau, McCormick & Mowbray.




  • A Bold Proper Noun heralds the first use of a term from the Glossary.




  • “Quoted Proper Nouns” are typically invitations to search the Internet and learn more about a peripheral topic.


TODO: should we replace this with a non-borrowed icon?


  • This borrowed icon besets links from the context to the Agile concepts.




  • monospaced words appear inside computers (but library and module names appear as Proper Nouns, and documenting comments appear in a normal roman font).




  • bold monospaced words are source code changes. The non-bold parts are often cloned code, then the bold parts are modifications.




  • italic monospaced fileglobs ?* are placeholders for reader-supplied values inside source code.




  • Pronounce empty parentheses as “the function” or “the method”. So “putSvgIntoCanvas()” becomes “the function put S, V, G into canvas”. This notation may elide arguments.




  • are keyboard key names.



Part I: One Button Testing


Test-first is rapidly becoming the leading software implementation technique. GUIs, by nature, resist any kind of test, and strongly resist test-first. This book proposes that a lean, right-sized test rig, grown with its target GUI, and using the same tools, can efficiently streamline development.


  • Chapter 1: The GUI Problem—Something about GUIs makes test-first very hard. We must isolate the problem before dealing with it.

  • Chapter 2: The TFUI Principles—A strategy to put any GUI under test with minimal overhead.

  • Chapter 2: GUI Architectures—Applying the strategy to each of the three kinds of GUIs, leading to specific development patterns.

  • Chapter 4: The Development Lifecycle with GUIs—placing the strategy into the larger context of teams and projects

Chapter 1: The GUI Problem


The reasons to write test cases before writing production code are simple yet subtle. The most compelling reason is to keep software easy to change over time. You might know how to write a new function, now, without its test, but a long time from now you might not realize how a change to another module could break this function. Nobody has perfect memory, and no team has perfect communication. Invest your understanding of your new function, now, into test cases that will raise an alarm if something breaks later. Run all the tests all the time. These simple rules boost development speed, while reducing the odds of debugging.

A recurring theme of this book is test cases must grow cheap and easy to write. When we test new code, as it grows, natural laziness provides simple and cheap tests. Each test case wants to test only one small behavior, so the tested function must have simple inputs and outputs. The test case should not construct every object in your program just to call that function. So that function will grow to decouple from other influences.

The most subtle and powerful effect of test-first is “emergent design”. Tests help your classes decouple from each other, when each test case shows a class performing alone without excess help from other classes. Decoupled classes are easy to change without affecting other classes. Designs that frequently change, under test, become very robust and flexible. This effect is easy to do and hard to talk about. It’s the main reason we take such small steps between each test run. Future chapters will illustrate some counterintuitive decisions, and will explain them with somewhat terse jargon.

This chapter uses a question and answer format to introduce that jargon. This early in the book, only thin metaphors and incomplete rationales can explain how to leverage testing. We must briefly reveal why test-first for GUIs is hard but important, and how programs with GUIs can improve their architecture to avoid complex techniques. The devils are in the details, and the next chapters will exorcize those.
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
обратиться к администрации
Библиотека
Главная страница