An Ihren Kindle oder ein anderes Gerät senden


Kostenlos testen

Jetzt kostenlos reinlesen

An Ihren Kindle oder ein anderes Gerät senden

Der Artikel ist in folgender Variante leider nicht verfügbar
Keine Abbildung vorhanden für
Keine Abbildung vorhanden


Test-Driven Database Development: Unlocking Agility (Net Objectives Lean-Agile Series) [Kindle Edition]

Max Guernsey III

Kindle-Preis: EUR 18,74 Inkl. MwSt. und kostenloser drahtloser Lieferung über Amazon Whispernet

Kostenlose Kindle-Leseanwendung Jeder kann Kindle Bücher lesen  selbst ohne ein Kindle-Gerät  mit der KOSTENFREIEN Kindle App für Smartphones, Tablets und Computer.

Geben Sie Ihre E-Mail-Adresse oder Mobiltelefonnummer ein, um die kostenfreie App zu beziehen.

Weitere Ausgaben

Amazon-Preis Neu ab Gebraucht ab
Kindle Edition EUR 18,74  
Taschenbuch EUR 34,82  



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.

Über den Autor und weitere Mitwirkende

Max Guernsey is currently a Managing Member at Hexagon Software LLC. He has 15 years of experience as a professional software developer. For nearly half that time, he has been blogging, writing, and delivering lectures on the topic of agile and test-driven database development. For much of Max's professional career, he has been a consultant, advising a variety of software companies in many different industries using multiple programming and database technologies. In most of these engagements, he spent months or even years helping teams implement cutting-edge techniques such as test-driven development, object-oriented design, acceptance-test-driven development, and agile planning. Max has always been a "hands-on" consultant, working with teams for long periods of time to help them build both software and skills. This series of diverse, yet deep, engagements helped him gain a unique understanding of the database-related testing and design problems that impede most agile teams. Since 2005, he has been thinking, writing, blogging, lecturing, and creating developer-facing software dedicated to resolving these issues. Max posts regularly on his Twitter account (@MaxGuernseyIII) and his blog (


  • Format: Kindle Edition
  • Dateigröße: 16477 KB
  • Seitenzahl der Print-Ausgabe: 334 Seiten
  • ISBN-Quelle für Seitenzahl: 032178412X
  • Gleichzeitige Verwendung von Geräten: Bis zu 5 Geräte gleichzeitig, je nach vom Verlag festgelegter Grenze
  • Verlag: Addison-Wesley Professional; Auflage: 1 (20. Februar 2013)
  • Verkauf durch: Amazon Media EU S.à r.l.
  • Sprache: Englisch
  • ASIN: B00BJ65RHA
  • Text-to-Speech (Vorlesemodus): Aktiviert
  • X-Ray:
  • Word Wise: Nicht aktiviert
  • Amazon Bestseller-Rang: #415.230 Bezahlt in Kindle-Shop (Siehe Top 100 Bezahlt in Kindle-Shop)

  •  Ist der Verkauf dieses Produkts für Sie nicht akzeptabel?

Mehr über den Autor

Entdecken Sie Bücher, lesen Sie über Autoren und mehr


Es gibt noch keine Kundenrezensionen auf
5 Sterne
4 Sterne
3 Sterne
2 Sterne
1 Sterne
Die hilfreichsten Kundenrezensionen auf (beta) 4.2 von 5 Sternen  4 Rezensionen
1 von 1 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen The best book I have read on databases 14. Januar 2014
Von Steven Ensslen - Veröffentlicht auf
_Test-Driven_Database_Development_ is the best book I have read on databases. I'm a professional database developer, with almost twenty years experience and certifications from multiple vendors.

This books describes the problems that plague business systems everywhere, and then clearly explains why they exist and simple processes to overcome them. Read this book and surpass your peers.

I agree with the negative review that at times the examples are challenging, and even that some of the terms are poorly chosen. But this book is truly brilliant and sorely needed. Invest the effort to learn its valuable lessons.
3 von 4 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen The Real Deal... THE book for TDDD 17. April 2013
Von T. Anderson - Veröffentlicht auf
I was a little wary of this book when I first saw it. No real specific red flag came up, just the general thought of yet another TDD book that magically unlocks agility.

The author caught me by surprise as I started to read the book. He starts off with the way we need to change our view of databases from that of a particular instance into one of classes of databases. This line of thought is what enables TDD in the database world.

The third chapter he covers the differences and relationship between test-first programming and test-driven development. He gets you thinking in the right frame of mind about TDD.

The book continues with details of the practices and patterns you need to know to succeed at TDD with databases. I have listed the chapters below.

Chapter 1. Why, Who, and What
Chapter 2. Establishing a Class of Databases
Chapter 3. A Little TDD
Chapter 4. Safely Changing Design
Chapter 5. Enforcing Interface
Chapter 6. Defining Behaviors
Chapter 7. Building for Maintainability
Chapter 8. Error and Remediation
Chapter 9. Design
Chapter 10. Mocking
Chapter 11. Refactoring
Chapter 12. Legacy Databases
Chapter 13. The Façade Pattern
Chapter 14. Variations
Chapter 15. Other Applications

Through the process of showing us how to change our view of databases, the author introduces a way of building and deploying databases using XML scripts. He use XML to define the changes to the database, and a library he wrote to handle the parsing the XML and update the database. That technique is used throughout the book.

I mention that because it may be easy to miss when the author says "I'll leave the implementation details to you, but I typically express the database design in terms of XML documents and store the already-applied versions in a table." I want to point that out because as you start going through the code it may get a bit overwhelming when you see how much work the author puts into the supporting library and XML documents. His tools include using NUnit also. There is an NUnit plug-in for Visual Studio 2012 available which makes running the tests and debugging while testing a lot easier.

The thing to keep in mind is that the author is introducing TDDD (Test Driven Database Design) practices and patterns and he is using the implementation method he has used for years. I accomplish the same thing as the author but I use Visual Studio's Unit Test Project template for tests, the SQL Server Database Project template for database scripts, and TFS for versioning, branching, and merging the tests and database scripts. The point is, keep reading because the author includes great advice throughout the entire book.

The code samples are very well organized and usable. After changing the connection strings and using NuGet to download Moq and NUnit, everything ran as expected. The author uses C# to write the tests and parse the XML he uses to define the database structure and changes.

The author's writing style makes the book an entertaining and enjoyable read.

Overall I highly recommend this book to developers, database administrators, enterprise architects, and software architects.
1 von 1 Kunden fanden die folgende Rezension hilfreich
5.0 von 5 Sternen It's that good. 15. Oktober 2014
Von Jay Holstein - Veröffentlicht auf
Format:Taschenbuch|Verifizierter Kauf
Exceptionally interesting, I'm going back to read it for the second time and running the code as I go. It's that good.
3 von 6 Kunden fanden die folgende Rezension hilfreich
2.0 von 5 Sternen Terribly written and incomplete 22. Oktober 2013
Von R. Wenner - Veröffentlicht auf
Bottom line: some good ideas, but overall terribly written, incomplete, and sometimes plain unusable.


Good (if not new or complicated) idea of scripting DB creation and migration. Good idea of test-driving data migration.

Some good advice here and there, e.g., to never user ... IF EXISTS in DDL (which the author later violates, but well).


Does not live up to its title: the mocking databases chapter is a joke. The refactoring chapter lacks as well. Many of the early chapters actually test the DBMS, not so much your own code by inserting and selecting that data again. This seems to be of questionable value to me.

Hard to read because the author invents his own lingo instead of using established terms (class vs schema, object vs database instance).

Leaves many questions due to lack of explanation; for example: "Building all that stuff in a batch might feel more efficient, but it's not." Why not? "I cannot convince you of that in a book" Why not even try?

Plain wrong: "Product code exists to make tests pass." No, product code exists to make customers happy. "If you're [...] changing design in a way that requires your tests to change [...], you probably shouldn't call it refactoring." Wrong. The simplest refactoring is renaming something and for that you will always have to change tests as well.

Unclear wording: class vs schema, transaction used as a table name (not as a database transaction), transition instead of data migration, information has different meanings (e.g., "Needed now is the information transmitted between a [...] database and its clients. Information is the database parallel to the concept of an interface").

Frequently complicated wording (did this book have a copy editor?): "The tricky bit of isolating behaviors is making sure that tests only receive information from one behavior at a time." That's blah-blah. You mock to keep stuff from messing up your tests, mocking is not about "tests receiving information".

The text is too verbose, some ideas are duplicated through the book.

Poor example code (lots of duplications, bad names).

Unwritten assumptions make it hard to follow the author's train of thought, especially early in the book where he assumes you hack DB changes on your production servers.

I am unclear about the target audience: on the one hand the author seems to assume you have no clue about TDD, on the other hand the description about e.g., mocking is so convoluted that it hardly makes any sense to beginners and can still befuddle people after years of TDD.


There is near to nothing on triggers and stored procedures.

The book has no references to anything (e.g. Mock objects paper, Refactoring book, Working effectively with legacy code, TDD books, agile introductory books, ...) It does not even mention dbunit, pgtap, or other DB testing tools. (The author has the lame excuse "I don't like stored procedures...")

Data migration is assumed to be a breeze or to fail quickly because of transition tests: ok, fair enough, but what if it takes hours? What if the underlying DBMS has changed and a complete dump and reload is required?

Detailed comments on the chapters:

Chapters 1 and 2:

The book starts confusingly. In chapters 1 and 2 the author tries to make the concept of objects and classes work for database schemas and instances without using the words schema and instance. The author never spells out his apparently underlying assumption that people just hack together a database and modify live instances instead of having DDL scripts under revision control. I frequently found myself scratching my head.

The idea to use XML for your script to transition from one DB schema (DB class in the author's lingo) version to the next is ludicrous. I have no clue how he can run that stuff easily and why he doesn't go for a plain old PL/SQL script for each migration step. XML adds a lot of noise. Additionally, you sacrifice syntax highlighting for the DDL statements.
Maybe that part was written a few years ago on the peak of all the XML fetishism.

The pseudo code just repeats what the text says and is so high-level that it is a waste of space.

Bottom line of chapters 1 and 2: If you already have version-controlled DDL scripts and migration scripts, don't read chapters 1 and 2. It has nothing new for you and the text can only confuse you.

Chapter 3

This is a TDD primer. It uses a database example, shwoing how to test-drive the design of the DDL scripts. This makes sense. (It's still beyond me why this is wrapped in XML.)

The debate about "Are tests tests or specifications?" could be interesting if you already have a solid TDD background, but may confuse TDD newbies. If you don't have a strong TDD background, skip that section. I disagree with the provided examples to use random data for testing (kills repeatability). The presented tests suffer from poor naming, not from tests vs specification. In either case they almost qualify as anti-patterns.

I like the point the author makes that tests should specify behavior, not structure. A few words more on this in the light of test-driving DDL code would have helped, cause DDL is all about (table) structures.

The section on defining the design inside out vs outside in is confusing as well. The author throws requirements changes on the first design and then compares that to a design that does not suffer from this.

Chapter 4:

This chapter repeats some of the earlier misconceptions in the book: Construction can mean to allocate memory for an object or to change the table structure while preserving the data --- clearly, the OO analogy would be (de)serialization, not creating new objects. It makes it hard to follow the author when you constantly have to double check his flawed assumptions.

Chapter 4 is good on explaining and showing how to test-drive DDL statements for the next database schema version. On top of that it layers another cool test of safeguards for the actual data in the production database that runs on upgrading and double checks the upgrade went fine.

The chapter suffers from switching example databases many times within the chapter, making it harder than necessary to follow the text.

Chapter 5:

This chapter builds an domain specific language to DRY up the database names. Certainly interesting, but I am not sure if it's worth the trouble, given the extra work and considering that DB views are an approach to minimize these problems that most people would be much more familiar with.

Chapter 6:

This is a verbose chapter that could be summed up as "hide your databse tables behind stored procedures". The author certianly has his point, but this chapter would be better suited in the beginner's guide to db design bible for dummies in 24 hours.

I do like the advice to not make the public interface of the database a simple CRUD design but design something to match the application's needs.

Chapter 7:

This repeats much of chapter 6, adding examples and anti patterns. Again, not much new unless you're a newbie with databases.

Chapter 8:

This has the weirdest definition of an error that I've ever seen: "has no unit tests". I thought that was the definition of legacy code.

The chapter goes downhill from here: nothing on how to avoid certain errors, nothing on debugging... it's just about adding an unit test and it's all good again. Dubious... The classification in "good" and "bad" errors seems quite strange as well. "Error" and "good" should be mutually exclusive, IMHO. Maybe "harmless" would have been the better word.

Chapter 9:

I don't get the separation in different databases for the sake of mimicing OO structures; maybe this makes more sense in the context of the next chapter on mocking. The advice on abstracting information out may work; I guess this always depends on the real use cases. The author does not go as far as to show you how to actually build these mocks, he just mentions separating parts of the database. It's up to you to put the right pieces together.

Chapter 10:

This chapter is on Mocking, and I thought it would get really interesting here. Unfortunately, after some convoluted explanations about testing in general, the author shows mocking in .NET code. WTF?! I thought this was a book on databases?

The chapter goes on with mocking databases, even though no logic happens in the database --- only tables, no stored procedures; it's all in application code. Hence the whole example is moot, cause to test anything you'd mock out the whole database here.

Assuming that you do want to test the database, the chapter falls short at putting the pieces together: how do I "link" the test databases and production databases together? How do I inject mocks? How do I clean the slate after or before each test suite?

I am missing a part about just recreating views and functions. After all, if these are the public interface to the database and databases are cleanly separated, wouldn't it be sufficient to just replace functions at the interfaces? Maybe the author tries to say that somewhere, but the text is just too incoherent.

Chapter 11:

The part about moving tables between instances seems trivial. Not sure how realistic this is. Reducing the duplication in the views is fine; I am unclear, however, on why the author considers this risky.

Chapter 12:

Standard working with legacy code dilemma (unmaintable mess of untested code) and how to solve it: get tests in piece by piece. This rehashes what has been said in earlier chapters: pinning the current table structures and adding tests. As above, this leaves out user management, triggers, views, and stored procedures.

There are some pointers on how to add a well defined interface to the legacy application (figure out what users really need, lock everything else). Not very database-specific; this would be the same for any legacy code with too broad interfaces.

Chapter 13:

This seems to add to chapter 12, just by calling the facade a facade. At this point I am happy that the author didn't redefine an existing term but went with the existing meaning of facade.

I am unclear why the author doesn't replace the legacy tables with views and migrates the data to the new table structure instead of keeping both old and new data.

Chapter 14:

To be honest, I don't understand most of this chapter. If a change was made in one version and corrected in the next one, how is it a refactoring to just do the corrected version? Won't that break everybody's databases?

When old versions of the code / database need to be patched, doesn't that call for the version control system rather than inventing elaborate patching mechanisms? Or maybe in this case an IF EXISTS is not such a bad idea in DDL statements after all.

Chapter 15:

This chapter extends the idea of scripting everything (and adding a unit test for this) to XML, the file system, and serialized objects.

If you were happy with the previous chapters, this is a nice conclusion.

If you thought (like I did) that there is plenty lacking: this holds for this chapter as well.
Waren diese Rezensionen hilfreich?   Wir wollen von Ihnen hören.

Kunden diskutieren

Das Forum zu diesem Produkt
Diskussion Antworten Jüngster Beitrag
Noch keine Diskussionen

Fragen stellen, Meinungen austauschen, Einblicke gewinnen
Neue Diskussion starten
Erster Beitrag:
Eingabe des Log-ins

Kundendiskussionen durchsuchen
Alle Amazon-Diskussionen durchsuchen

Ähnliche Artikel finden