| 
  • If you are citizen of an European Union member nation, you may not use this service unless you are at least 16 years old.

  • You already know Dokkio is an AI-powered assistant to organize & manage your digital files & messages. Very soon, Dokkio will support Outlook as well as One Drive. Check it out today!

View
 

Styles of TDD

Page history last edited by PBworks 15 years, 6 months ago

Bill Wake and Naresh Jain facilitated this workshop.

 

We looked at 3 system descriptions as a basis for thinking about "What's your first test?" and "What tests you are going to write next?": a wiki, a veterinary clinic billing system, and a conference scheduler.

 

We started with the wiki problem and most groups started with an acceptance test for a new page, testing its title and some other validation. One group did start with a unit test, where they created a page object and tested details about the page from an implementation stand-point.

 

Naresh introduced a version of Brian Marick's matrix for testing:

 

Business Facing, Drives Development: e.g., acceptance tests, low-fi prototypes Business Facing, Critiques Development: e.g., automated UI tests, exploratory testing
Technology Facing, Drives Development: e.g., unit tests Technology Facing, Critiques Development: e.g., stress, system, security tests

 

He talked about "outside-in" tests that start from the upper left quadrant (Business facing) and go down (Technology/Implementation facing), and "inside-out" tests that start at the unit test level and work up. Most developers using the inside-out approach tend to identify the core of the system and test drive outwards, the rest of the system. He also pointed out that in his experience a lot of people jump between these 2 styles, but overall the system design is largely influence by one style. 

 

We noted that early on, it can be ambiguous whether a test is at the acceptance or unit test level. One person's claim: "Acceptance tests are written in a language the customer can understand." (Not clear everyone agreed with that.) Another claim: "Acceptance testing tests a unit from the customer's perspective." Some people refer to this as Customer Unit Tests.

 


 

What was the basis for a test?

 

  • New objects
  • Low-level details, e.g., business rules
  • Interesting challenges (most risky)
  • Setting up yourself for the next thing

 

We talked about a hill-climbing problem - the space we explore is not gently sloping up, but has hills. We'd like to get to the highest point. But we may get to the top of this hill, only to find that there's a taller hill; to get there we have to backtrack. The question is - how far must you backtrack?

 

This particularly came up in the conference scheduler system. Depending on the order of stories, it can look first like a day-timer or tracker, but at some point automatic scheduling might add constraints that fit better with a more constraint-oriented system. (E.g., don't double-book people or rooms.) When do you shift "metaphors"? What do you gain or lose when you do so?

 


 

We considered some dimensions, and placed dots to say where we were on that dimension.

 

Unit Test --xxxx---X-------xx Acceptance test
API x-xx---xxXx---x---- User interface
State -x-x-x---Xxxx------ Interaction
OO xxxxx----X--------- Procedural
Easy first ---------X-----xxxx Core first
Narrow -xxxx---xX--------x Broad
Drive design -xxx--xxxX--------x Validate design

 

After everyone plotted their dots, Naresh made a claim (what he says a rather controversial statement) that developers who use purely inside out approach, .i.e. use unit tests to drive their development, are really using tests to validate their design and not so much to drive the design. More details here : "Unit Tests Validates Micro-Design". There was a good disucssion on this topic and looked like actually some people agreed.

 

More discussion pointed out that the breakdown of stories affects the design. Naresh summarized his thoughts on his blog post : "When does design begin?"


 

Session was held 8-5-08, at Agile '08 in Toronto.

 

Comments (0)

You don't have permission to comment on this page.