Here is a breakdown of the talk:

1. Agile Principles
   We delve into Agile principles and assumptions to establish why it works so well for programming. I spend the bulk of this time talking about the principle of Emergent Design and how the evolutionary model facilitates this in the programming world.

2. New Forces in the World of Data
   We cover how the forces in the database world differ from those in programming. Here, I show that, while Emergent Design is still of paramount importance, the concept of evolution is essentially useless and introduce “metamorphosis” as an alternative model for introducing new traits to a database.

3. Repeatability as a Major Concern
   I show that all of the strictures we place upon ourselves in the world of programming are there to increase the reliability of what gets built and draw the inference that a virtually one-hundred-percent reliable build process is required in the database world as well. I also supply one example of a process that is fully repeatable. I introduce transition testing and show how it creates a “class” of databases and thus facilitates test-driven development and design.

4. The Test-Driven Database
   I cover test-driving databases. Here, I first discuss how unit and acceptance tests apply to the database world. Then I explain why they tend to not work. There is no “class” of databases so they are difficult to treat as fixtures. I introduce transition testing and show how it creates a “class” of databases and thus facilitates test-driven development and design.
   Removed due to time constraints.

5. Transition Testing in Action
   Finally there is a short case study. This is done at a really high level and meant to drive home everything that was learned in the previous sections.

6. Question and Answer
   Most questions will probably have been dealt with during the body of the session but I will leave a little time at the end for “general” Q&A. I usually make myself available after presentations for questions, as well.

Additional information about transition testing:

Transition testing is just like any other kind of test in that it has the same basic anatomy: Setup, Trigger, and Assertion. Since all tests seem to have these parts, the thing that really distinguishes them is the purpose they fill. The distinction between “acceptance” and “unit” tests, for instance, is that the former verifies that you are designing the right thing and the latter that you are designing the thing right.

Transition tests prove that you are building your database correctly. There is an implication, here: the thing that builds your database must be fully testable (which usually means automated, as well). In fact, initially, this is what I would try to get people to do first with the intent of introducing transition testing in second. Shortly thereafter, I realized that it was easier to hook someone on transition testing and just bring the fully automated and testable database builds along as a prerequisite.

A transition test is a test in which we take the following steps:

1. (Setup) Put the database in one behavioral state (e.g.: A particular schema version)

2. (Setup) Populate the database with any required sample data - keep it small

3. (Trigger) Initiate a shift in the database’s behavioral state (e.g.: Move to the next schema version)

4. (Assertion) Check that part of the transition from the source state to the target state worked (e.g.: Test that a new structure was added, test that data were properly transformed)

You can find the materials for the session at the following links:

http://tinyurl.com/MG3-Agile2009-Code
http://tinyurl.com/MG3-Agile2009-Slides
http://tinyurl.com/MG3-Agile2009-FIT