- ホーム
- > 洋書
- > 英文書
- > Computer / Databases
Full Description
The practice of Test-Driven Development (TDD) has helped thousands of software developers improve quality, agility, productivity, and speed. In Test-Driven Database Development, Max Guernsey, III shows how to adapt TDD to achieve the same powerful benefits in database design and development.Guernsey first explains why TDD offers so much potential to database practitioners, and how to overcome obstacles such as the lack of conventional "testable classes." You'll learn how to use "classes of databases" to manage change more effectively; how to define testable database behaviors; how to maximize long-term maintainability by limiting a database's current scope; and how to use "emergent design" to simplify future expansion.Building on this foundation, the author guides you through implementing modern TDD processes and database refactoring. He presents practical techniques for improving legacy databases; for deviating from strict TDD when necessary; and for adapting TDD to applications that persist data in file systems, XML, or serialized objects. Guernsey shows how to* Build a simple infrastructure to track and standardize scripts and databases* Define a sustainable TDD process for database design* Safely change a design without losing data* Design new databases that are lighter, leaner, simpler, more testable, and easier to change* Reduce design costs by eliminating duplication* Gradually bring the benefits of TDD, agility, and modern design to legacy databases* Remediate errors that find their way into database designs* Isolate behaviors and avoid unwanted dependencies that cause tests to failWith this book as a guide, you will learn how to apply the proven practice of TDD to your database needs, and organize and optimize your organization's data for a significant competitive advantage.Test-Driven Database Development is the newest title in the highly respected NetObjectives Lean-Agile Series.
Contents
Foreword xviiPreface xixAcknowledgments xxvAbout the Authors xxviiChapter 1 Why, Who, and What 1Why 1Agility Progressively Invades Domains Every Day 2Agility Cannot Work Without TDD 2TDD in the Database World Is a Challenge 3Who 3TDD and OOP 4Applications and Databases 4What 4Databases Are Objects 5TDD Works on Classes, Not Objects 5We Need Classes of Databases 6Summary 7Chapter 2 Establishing a Class of Databases 9The Class's Role in TDD 9A Reliable Instantiation Process 10Tests Check Objects 10Classes in Object-Oriented Programming Languages 11Making Classes Is Easy: Just Make New Objects 11One Path: Destroy If Necessary 11Classes of Databases 12Two Paths: Create or Change 12The Hard Part: Unifying the Two Paths 13Real Database Growth 13How About Making Every Database Build Like Production Databases? 14All DBs Would Follow the Exact Same Path 15Incremental Build 15Document Each Database Change 15Identify Current Version 16Apply Changes in Order as Needed 16Implementation 16Requirements 16Pseudocode Database Instantiation Mechanism 17Pseudocode Input 17Summary 18Chapter 3 A Little TDD 19The Test-First Technique 19Write the Test 20Stub Out Enough to See a Failure 22See the Test Pass 22Repeat 23Tests as Specifications 24"Tests Aren't Tests, They Are Specifications" 24"Tests Aren't Specifications, They Are Tests" 25Tests Are Executable Specifications 26Incremental Design 27Building Good Specifications 28Specify Behavior, Not Structure 28Drive Design In from Without, Not the Other Way Around 29Defining the Design Inside Out 30Defining the Design Outside In 32Summary 34Chapter 4 Safely Changing Design 37What Is Safe? 38Breaking a Contract Is a Little Bad 38Losing Data Will Probably Get You Fired 39Not Changing Design Is Also Dangerous 40Solution: Transition Testing 44Test-Driving Instantiation 44Transition Testing Creation 44Transition Testing Addition 47Transition Testing Metamorphosis 51Why Not Use the Public Interface? 56Transition Safeguards 56Read/Read Transition Tests 56Run by the Class of Databases on Every Upgrade 60Backup and Rollback on Fail 60Making Transition Tests Leverage Transition Safeguards 60Summary 61Chapter 5 Enforcing Interface 63Interface Strength 64Stronger Coupling Languages 64Weaker Coupling Languages 65The Common Thread 66Coupling to Database Classes 66The Problem Is Duplication 66Client-Object-Like Enforcement 67Creating Demand for a DatabaseDesign Class 67Specifying the DatabaseDesign Class 68Getting Rid of Duplication with Multiple Client Platforms 70What Happens When Coupling Goes Bad? 71Eliminating Duplication Between Database Build and Client Code 71Decoupling Implementation from Design 72Sticking Point: Change 73Designs Change Over Time 74Document All Versions of Design 75Couple to the Correct Version of the Design 77Sticking Point: Coupling 78Various Clients Couple to Various Versions 78Having to Change Everything All the Time Is Duplication, Too 79Introducing the Lens Concept 83Virtual Lenses 85The "Current" Lens 89The "New" Lens 89Summary 93Chapter 6 Defining Behaviors 95A New Group of Problems 96No Encapsulation 96Hide Everything 97Business Logic in the Database 97Knowledge, Information, and Behavior 98Information 99Knowledge 102Behavior 102Outside-In Development 106Defining the Test 106Growing Interface 108Growing Behavior and Structures 109Justification by Specification 111Work Against Present Requirements, Not Future 111Build in Increments 112Limit Access to What Is Specified 112Summary 113Chapter 7 Building for Maintainability 115Never Worry About the Future 116Look for Opportunities in the Now 116Design to Information 117Translate Info and Knowledge with Behavior 121Guard Knowledge with Fervor and Zeal 124Not Changing Is the Most Dangerous Choice 124Keep Your Design Natural 126Deal with the Future When It Happens 127Define New Design 128Introduce Minimal Changes 129Get Tests Passing 131Stop, Think, Refactor 133Summary 136Chapter 8 Error and Remediation 137Kinds of Errors 137Axis: Is the Error Good or Bad? 138Axis: Is the Error Released or Not? 140Dealing with Good Errors 142Just Fix It 142Document Behavior Now 143Trace Feature Back to Its Genesis 145Dealing with Bad Errors 146Unreleased Errors 147Released Errors 150Catastrophic Errors 156Summary 157Chapter 9 Design 159Structures Versus Design 160Structures: Execution Details 160Tests and Class Information 162What Is Design? 163Buckets of Concepts 163Mandatory Part of True TDD 166Composition and Aggregation 167Composition: One Thing with Multiple Parts 168Aggregation: Connecting Distinct Things 172Reuse 175Avoid Developing the Same Thing Twice 175Reuse by Composition or Aggregation 177Abstraction 178Identifying Opportunities for Abstraction 178Encapsulating Behaviors 179Finding Ways to Allow Variation in Dependencies 185Dealing with the Time Problem 186Summary 190Chapter 10 Mocking 191Testing Individual Behaviors 191Why Encapsulate 192Tests Test Everything Not Under Their Control 193Controlling Irrelevant Behaviors from Tests 194Mocking Controls Behaviors 194Mocking in Object-Oriented Programming 195Setup 195Decoupling 199Isolation 202Integration 202Mocking in Database Design 203Example Problem 204Example Solution 205Composition 208Aggregation 210Designing for Testability 210Summary 210Chapter 11 Refactoring 213What Refactoring Is 214Changing Design Without Changing Behavior 214In the Context of Passing Tests 215Lower and Higher Risk Design Changes 222Lower Risk: Changing Class-Level Design 222Medium Risk: Rearranging Behavior Logic 223Higher Risk: Altering Knowledge Containers 225This Is Not an Invitation to Skip Testing 226Summary 226Chapter 12 Legacy Databases 227Promoting to a Class 228Deducing Initial Version 228Pinning the Transition Behavior with Tests 231Controlling Coupling 231Identifying and Locking Down to Existing Uses 232Encapsulating on Demand 234Controlling Change 235Test-Driving New Behaviors 235Pinning Construction on Demand 237Pinning Behavior on Demand 238Implementing New Behavior 239Finding Seams and Components 240Finding Seams 240Encapsulating Components 243Summary 247Chapter 13 The Facade Pattern 249Encapsulation with a Facade 249Explanation of Facade Pattern 250New Test-Driven Facade Database 254Compositional Alternative 261To Encapsulate or Not 261Strangling the Old Interface 262Transferring Changing Behaviors to Facade 262Removing Access and Features When No Longer Needed 263Test-Driving Behaviors in the Facade Database 264Exposing Legacy Behaviors 265Another Way to Do It 265New Behaviors 266Summary 266Chapter 14 Variations 269Having a Class Is Important-Implementation Is Not 270Scenario: Skipping Steps 270Problem 271Solution 272The Right Amount of Work 273Scenario: Deviations 274Problem 274Solution 275Solution Applied 277Common Solution 281Summary 281Chapter 15 Other Applications 283XML 284Encapsulation 284XSD Schemas 284XSLT Transitions 286Transition Test XSLT Changes 287File Systems and Other Object Directories 288Transition Test File System Manipulations 289Shell Script Transitions 291Data Objects 292Class Definitions Are Schemas 292Transition Test the Ugrader Class 294Code Transitions 296Summary and Send Off 300Index 301
