Test-Driven Database Development: Unlocking Agility, Rough Cuts

Description

• Copyright 2013
• Dimensions: 7" x 9-1/8"
• Pages: 352
• Edition: 1st

• Rough Cuts
• ISBN-10: 0-13-277649-9
• ISBN-13: 978-0-13-277649-3

This is the Rough Cut version of the printed book.

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 fail

With 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.



Sample Content

Table of Contents

Foreword      xvii
Preface      xix
Acknowledgments      xxv
About the Authors      xxvii

Chapter 1  Why, Who, and What      1
Why      1
   Agility Progressively Invades Domains Every Day     2
   Agility Cannot Work Without TDD     2
   TDD in the Database World Is a Challenge     3
Who     3
   TDD and OOP     4
   Applications and Databases     4
What     4
   Databases Are Objects     5
   TDD Works on Classes, Not Objects     5
   We Need Classes of Databases     6
Summary     7

Chapter 2  Establishing a Class of Databases     9
The Class’s Role in TDD     9
   A Reliable Instantiation Process     10
   Tests Check Objects     10
Classes in Object-Oriented Programming Languages     11
   Making Classes Is Easy: Just Make New Objects     11
   One Path: Destroy If Necessary     11
Classes of Databases     12
   Two Paths: Create or Change     12
   The Hard Part: Unifying the Two Paths     13
   Real Database Growth     13
   How About Making Every Database Build Like Production Databases?     14
   All DBs Would Follow the Exact Same Path     15
Incremental Build     15
   Document Each Database Change     15
   Identify Current Version     16
   Apply Changes in Order as Needed     16
Implementation     16
   Requirements     16
   Pseudocode Database Instantiation Mechanism     17
   Pseudocode Input     17
Summary     18

Chapter 3  A Little TDD     19
The Test-First Technique     19
   Write the Test     20
   Stub Out Enough to See a Failure     22
   See the Test Pass     22
   Repeat     23
Tests as Specifications     24
   “Tests Aren’t Tests, They Are Specifications”     24
   “Tests Aren’t Specifications, They Are Tests”     25
   Tests Are Executable Specifications     26
   Incremental Design     27
Building Good Specifications     28
   Specify Behavior, Not Structure     28
   Drive Design In from Without, Not the Other Way Around     29
   Defining the Design Inside Out     30
   Defining the Design Outside In     32
Summary     34

Chapter 4  Safely Changing Design     37
What Is Safe?     38
   Breaking a Contract Is a Little Bad     38
   Losing Data Will Probably Get Yo



Updates

Submit Errata

