Agile in a Flash 44

A Rhythm for Success: The TDD Cycle – The Code

Agile in a Flash by Jeff Langr and Tim Ottinger (card #44)

> Red

> Green

> Refactor

--

Of the agile developer practices, TDD will change your coding approach most fundamentally. TDD is a rhythm that helps you continually keep steady, forward progress. In the TDD cycle, you produce enough test code to fail, produce enough code to make the test pass, and then refactor before writing the next microtest. Red and green are the colors shown by GUI test tools for failing and passing tests.

Red. Newbies commonly make the mistake of not watching tests fail first. The red is essential feedback that the tests are written correctly and recognized by the test runner.

Green. Making the test pass is the part that is obvious; the hard part is that you write only enough code to make the test pass. No more! By limiting the amount of coding, you force the tests to be more complete, you avoid the cost of an over-designed system, and you learn how to incrementally grow behavior.

Refactor. While the test is passing, before anyone can depend on its current implementation, clean it. Rename a test. Improve readability. Extract an interface or a class. Unlike the Green step, there are no limits on the amount of refactoring you can do per step, as long as the tests always pass. Refactoring is critical to survival; it is your main opportunity to ensure your system’s

design stays clean.

“All code is guilty until proven innocent”

Agile in a Flash 38

Stop the Bad Test Death Spiral – The Team

Agile in a Flash by Jeff Langr and Tim Ottinger (card #38)

> Only integration tests are written ! Learn TDD.

> Overall suite time slows ! Break into “slow/fast” suites.

> Tests are run less often ! Report test timeouts as build failures.

> Tests are disabled ! Monitor coverage.

> Bugs become commonplace ! Always write tests to “cover” a bug.

> Value of automated testing is questioned ! Commit to TDD, acceptance tests (ATs), refactoring.

> Team quits testing in disgust ! Don’t wait until it’s too late!--

Each misstep with TDD may lead down a bad spiral toward its abandonment.

Learn TDD. Violating cohesion and coupling principles impedes unit testing and promotes integration tests instead. TDD drives a unit-testable, SOLID (OO Design Pattern) design.

Break into slow/fast suites A fast suite runs in ten seconds. Keep the slow suite small. Use a continuous test tool such as Infinitest (Selenium works well too). Keep coupling low.

Report test timeouts as build failures Continually monitor the health of your test suite. If the suite slows dramatically, developers soon skimp on testing.

Monitor coverage Seek coverage above 90% on new code and stable/increasing coverage on existing code. Recast integration tests as unit tests or ATs.

Always write tests to cover a bug Test first, of course. Defects indicate inadequate test coverage. Track and understand each defect’s root cause!

Commit to TDD, ATs, refactoring Do TDD diligently. Many bugs are rooted in duplication that you must factor out. Quality problems slow production!

Don’t wait until it’s too late! If you admit defeat, it may be too late—managers rarely tolerate second attempts at what they think is the same thing.

From experience, Avoid building tests that encompass more than the subject or code tested or the test becomes overly complex and “brittle.”