FitBookNotes

For the 2005-11-01 meeting, I did a presentation on the book "Fit For Developing Software" by Robert C. Martin [Amazon]. I would recommend the book to anyone interested in learning how to use tests to facilitate communication with your customers. It also has good coverage on how to structure and implement FIT tests.

After taking notes on the points covered in the book that I thought were most interesting, I rearranged them into a semi-coherent presentation. Here are my notes for that presentation. This presentation focuses more on the "why" half of the book, though the book has a very good "how" half as well.

---

Writing tests can be a simpler and faster way to get feedback than mocking up a GUI or building a prototype app.

Tables: clear and simple structure; everyone understands and can use

Can brainstorm story card by writing (action/flow) test tables.

• clarify steps, required info, wording
• makes concrete example for story
  • makes corner cases more obvious so they can then be clarified
• brings customer into the "design"
  • story card requires more communication, test tables increase clarity of communication due to concreteness. And as a side effect, produce a usable artifact.

--

Book addresses three "problems": Communication, Agility, Balance

• Communication: tables are concrete. stories: clear example before general case. create "ubiquitous language"
• Agile: tests support fast change
• Balance: less time fixing problems by reducing number and severity, catching them early, and ensuring they don't return.

Two kinds of business rule: 1) calculations / decisions and 2) processes (steps)

--

How FIT fits in XP:

Normal XP: create story -(A)-> devs estimate -> choose stories for iteration -(B)-> develop -> done when all tests pass and no outstanding issues

FIT: at (A): create initial rough FIT tests. at (B): more FIT tests - towards final set

Note: tests and development in parallel, though tests get a head start

--

Good starting points for first FIT tests (pg 102):

• needs attention due to errors
• simple and clear business rules
• no tests, or marginal tests
• have people familiar with biz and with testing, and eager

When adding tests to existing code, start simple and build up; simplify problem until you get a foothold

Throw something up, then improve

Don't get hung up on non-fundamental issues

• ex: complete; comprehensive tests
• ex: GUI changing frequently
• ex: code to be tested is hard to reach
  • in these last two cases, FIT tests can be written to test through the GUI if necessary. However, concentrate on abstraction when writing the tests
• tests need not strictly follow the current implementation - should follow the business logic (p109)
• the essence should match
• keep tests simple (clear) and do grunge work in fixture
• tech people may have to design tables; biz people can add to them, following the established pattern (oh no - work together!)
• Tests aim to communicate the business rules as clearly as possible, with a focus on the essential, ignoring incidental details of the implementation.

--

Refactoring

Once you have tests, they can be refactored (p106)

• make column labels clear and descriptive
• pull out common setup
• split up multiple concepts into multiple tables. In a chain of calculations, may want to do each link separately.
• can use multiple tables with same fixture to keep tests clear (each tests one aspect / parameter)
• might find fuzzy thinking exposed and need to get clarification
• with flow tests, can make repeated parameters implicit
  • "set and forget" / scoped
• may take several refinement passes to get good tables - tests will evolve
• see section 14.6, p112 (?)
• don't forget sad-path tests
• may want to make conceptual business objects (such as transactions) explicit in tables
• when you find you have many similar workflow tests, you may find you can collapse these into a few calculation tests, cutting to the essential nature of the business rules.

--

Common fixture types:

• Column Fixture: test per row (for calculations)
• Action Fixture: process (see also flow fixture)
• Row Fixture: check contents of a collection (eg, query results)
• Flow Fixture (Do fixture): process or multi-phase test
• Custom Fixture: special situations

--

Technique: can pass params that affect whole table on first line (using Do Fixture and fixture swapping) (p129)

Test maintenance problems can be a sign that business rules are not being expressed in the most direct way

• test will evolve

--

Principles of Test Design: section 18.1 (p155)

smells: meaningless numbers; poor names; brain twisters; unnecessary details; tangled tables; split values; long tables

workflow smells: missing sad paths; calculations slow with workflow (workflow used to test calculations); long workflow tables; unclear workflow; missing tests (need 0, 1, n); rambling workflow (use Do Fixture); similar setup; convoluted setup

calculation smells: many columns; not calculating; many rows; no related workflow

list smells: too many list columns; too many list rows

smells: duplication; tests changing often

Keep automation in mind - don't do things that aren't automatable:

• organize
• don't assume order - should be stand alone and independent
• provide useful feedback when a test fails

--

Summary p172