Astels D., Test-Driven Development (2003)

 |  Book Reviews

The book itself is quite heavy but, unlike other TDD books, it puts TDD after modeling which cardinally helps to start applying TDD in practice. Most valuable content is reviewed.

Contents

Summary

Contrary to Beck's Extreme Programming books 1 this book has a useful Appendix B. AGILE MODELING (p. 634) that extensively explains the need and principles of modeling before TDD.

Disregard the nowadays omnipresent "agile" 2 suffix. Any decent modeling approach will work. Now an important quote from the author.

[D. Astels] Some people will tell us that "if you're taking a test-driven development (TDD) approach to development that you don't need to model." Those people are completely and utterly wrong. These are probably the exact same people who also told us that "you don't model on an extreme Programming (XP) project," and they were completely and utterly wrong about that, too.

That is a good promise. Read on.

[INFO] I did not review the rest of the book in details due to concrete reasons but here is quick overview.

"Part I, Background" is too multi-purpose - trying to review in turn the XP, TDD, refactoring, software engineering (programming) - that gets as a waste with no value compared to the brightest books dedicated to each of the subjects. You can find many of them reviewed on this site.

"Part II, Tools and Techniques" (p. 84) despite focusing on Java JUnit (ch. 4) it is good for you to read yourself to understand xUnit interface used in many languages' test frameworks.

Now skip to the first half of Chapter 7 for a good light introduction of mocking.

"Part III, A Java Project: Test-Driven End-to-End" (p. 255). Quite valuable reading because modeling is presented being engaged before TDD. For a C-family language engineers, the syntax will not be an obstacle to grasp the entire thing.

Appendix B. Agile Modeling

The Modeling Myths

(p.635)

  • Model = Documentation
  • You Can Think Everything Through From the Start
  • Modeling Implies a Prescriptive Software Process
  • You Must "Freeze" Requirements
  • Your Design is Carved in Stone
  • You Must Use a CASE Tool
  • Modeling is a Waste of Time
  • The World Revolves Around Data Modeling
  • All Developers Know How to Model

Intro to Agile Modeling

(p. 637)

Goals

Principles
  • Assume Simplicity
  • Content Is More Important Than Representation
  • Embrace Change
  • Enabling the Next Effort is Your Secondary Goal
  • Everyone Can Learn From Everyone Else
  • Incremental Change
  • Know Your Models
  • Local Adaptation
  • Maximize Stakeholder Investment
  • Model With a Purpose
  • Multiple Models
  • Open and Honest Communication
  • Quality Work
  • Rapid Feedback
  • Software is Your Primary Goal
  • Travel Light
  • Work With People's Instincts
Practices (p. 640)
  • Active Stakeholder Participation
  • Apply Modeling Standards
  • Apply Patterns Gently
  • Apply the Right Artifacts
  • Collective Ownership
  • Consider Testability
  • Create Several Models in Parallel
  • Create Simple Content
  • Depict Models Simply
  • Discard Temporary Models
  • Display Models Publicly
  • Formalize Contract Models
  • Iterate To Another Artifact
  • Model in Small Increments
  • Model to Communicate
  • Model To Understand
  • Model With Others
  • Prove it With Code
  • Reuse Existing Resources
  • Update Only When It Hurts
  • Use the Simplest Tools

What Are Agile Models

Agile models:

  • fulfill their purpose
  • are understandable
  • are sufficiently
    • accurate
    • consistent
    • detailed
  • provide positive value
  • are as simple as possible

That's was the core value of the book.

Footnotes

  1. Extreme Programming Explained, Planning Extreme Programming, TDD by Example; In these books software modeling (design) is vaguely defined as "organic design" with no concrete clarification neither referencing what it is. ↩

  2. Which, in fact, as simple as managerial common sense wrapped in a shiny term, as if it would have helped anyone magically bring the product value. ↩