KentBeck TDD byexample,

[ Pobierz całość w formacie PDF ]
//-->Test-Driven DevelopmentBy ExampleKent Beck, Three Rivers InstituteNotes to reviewers:•Are there diagrams that would help orient the examples?•Section I: Money Example is now completely re-written. Does the new style workbetter than the old one? I have noticed several changes—shorter chapters, morecareful adherence to “the rules”, less American-isms. Better, worse, same?•Please suggest your favorite glossary items•How does the new how/why refactoring format work? Do I need an example, or isit sufficient to point people to Martin’s book?Publically availabe atTest-driven developmentCopyright © 2002 Kent Beck, All Rights Reserved3/8/02, 132 PagesTest-driven development2 of 132To DoGlossaryTo-do lists, chapter hooks, and reviews for xUnitConvert to Frame (sigh…)Finish missing patternsBold source code changesRun Money through Jester and a coverage toolDeadend in Money. Where, oh where?Test-driven development3 of 133Random ThoughtsAnother mental picture—programming is like exploring a dark house. You go fromroom to room to room. Writing the test is like turning on the light. Then you can avoidthe furniture and save your shins (the clean design resulting from refactoring). Thenyou’re ready to explore the next room.I need an adjective which means “can be made to work in one step”. Atomic?Achievable? Progressive?At the different stages of the cycle you are solving different problems, so theaesthetics change: Write a test-what should the API be? Make it compile—do as littleas possible to satisfy the compiler. Make it run—get back to green so you haveconfidence. Refactor—remove duplication to prepare for the next test.Interesting error. I had two tests, one USD->USD and one USD->GBP. If I had keptthe two assertions in the same test I wouldn’t have gone off the rails. What’s the rulethere? When do you add assertions to existing tests and when do you write a new test?Splitting into orthogonal dimensions didn’t happen in either example. What up withthat? I thought that was such an important technique. Maybe that’s what “isolatechange” is really about, and taking smaller steps than I usually do results in makingprogress along one dimension before having to make progress in the other.More orientation material at the beginning of the example chapters—UML, lists oftests running, to do listBrian Marick on test-first tests as tests?TDD as a gesture—technical, political, aesthetic, emotional. Relationship to otherpractices.Since people are likely to read the chapters in the example one or two at a time, it isimportant to provide context at the beginning of each one-UML, maybe a list of thetest cases that are running at the beginning.Test coverage. Use data structures that make special cases go away- iterators, number-like numbers.Balancing reasoning and testing. Every one of those reasoning steps is subject to error,which adds risks. Replacing each and every reasoning step with a concrete test isextremely expensive (impossibly expensive, really). There is some tradeoff. Maybethat’s part of being a TDD—being aware of tradeoffs and intelligently choosing thecrossover point for this particular situation.Assuming a certain geekoid value system—you want to do well by doing good (orvice versa). That is, you like clean code, you enjoy the feeling of designing andbuilding well, and you want to be seen to be successful by managers and customers.Code aesthetics. For any given set of test cases, we are trying to minimize acomplicated cost function—number of classes, number of methods, number of uniqueselectors, number of arguments, complexity of flow of control, visibility of methodsTest-driven development4 of 133and members, coupling and cohesion. Either that or we are trying to give ourselves aglimpse through a tiny keyhole at an eternal realm of dynamic order.Once and only once—part of philosophical underpinnings. Also emergence. Howabout the attractor stuff Phlip talks about? Make it run, make it right, make it fast.Concrete to abstract, existential to universal.“Clever” play on words in the title. Test-driven developmentisdevelopment byexample. The book is also structured by example.One paragraph of my history with TDD (preface?)What exactly is the relationship between test cases and design patterns? Test cases andrefactorings?Tease apart “test-driven development”.This book is another example of my overall quest to find fundamental rules underlyingeffective software development. I’m looking for a theory in the physics sense, but Ialways take something I enjoy doing, subject it to a microscopic examination, and seeif following simple rules enhances my enjoyment. Software patterns in general, SBPP,XP, and now this all have the same form.Test-driven development5 of 133ContentsTO DORANDOM THOUGHTSCONTENTSPREFACEFearAcknowledgementsSTORY TIMESECTION I: MONEY EXAMPLEMONEY EXAMPLEDEGENERATE OBJECTSEQUALITY FOR ALLPRIVACYFRANC-LY SPEAKINGEQUALITY FOR ALL, REDUXAPPLES AND ORANGESMAKIN’ OBJECTSTIMES WE’RE LIVIN’ INTHE ROOT OF ALL EVILADDITION, FINALLY2359101113151622242729323537404551 [ Pobierz całość w formacie PDF ]
  • zanotowane.pl
  • doc.pisz.pl
  • pdf.pisz.pl
  • klobuckfatima.xlx.pl