RailsConf 2007: Intro to TDD for Rails

TDD and Refactoring, with a dash of Extreme Ping Pong…

Intro to Test-Driven Development for Rails – David Chelimsky

We all love to hack, deep in our holes. – David Chelimsky

Description

Test-Driven Development is a design and testing practice in which the developer writes the test before the code being tested. Practiced with discipline, TDD can lead to cleaner, more flexible designs that are implicitly testable and, consequently, more easily maintained over the lifetime of an application.

In this hands-on tutorial, we’ll go through the basics of TDD, beginning with a simple Ruby program and then moving onto a Rails application. This is intended for Rails developers of any level (but with at least some novice Ruby and Rails experience) who have little or no previous TDD experience.

Extreme Programming Practices

• User Stories => expressing simple requirements from the perspective of a user in the system. forces developers and users to talk about the details during the development process (versus documenting the whole thing up front)
• Customer Acceptance Tests
• Test Driven Development
• Pair Programming (increases the bus number)
• Refactoring => change the structure of the code without changing the behavior of the code
  • assumes you have the right tests and enough tests => not infallible

“Clean Code That Works” => The Goals of Test-Driven Development

What the hell was I thinking earlier today? - David Chelimsky

• It’s cheaper to do something right than to do it over.
• Will feel slower initially.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. - Martin Fowler

• code should tell its own story
• tests tell how the code fits together.

TDD Demo

• Ping Pong => one programmer writes a failing test, the other programmer makes the test pass
• what is the error and how do I make it go away?
• test/unit ships with ruby => looks for method names starting with test, catalogs them and reinitializes the test class, creating a new instance for each method
• assert asserts the existence of an object (nil makes it fail, 0 is an object, so it would pass)
• try to have 1 assertion per method
• “tell, don’t ask” => instead of asking an object for stuff, tell it to do stuff. results in more loosely coupled systems.
• read fowler’s refactoring book
• TDD is about design
• don’t write any code except to make a test pass => sometimes seems counter-intuitive
• code is a liability, not an asset
• clarity is king in tests, not DRY
• DRY is about objects, not typing
• weigh duplication against clarity
• setup comes from test/unit, runs before each method
• good names are vital
• reduces the number of up-front decisions you have to make. postponing decisions is a competitive advantage.
• test collections for 0, 1 and 3
• code dojos
• rspec and bdd

TDD Cycle

• write a small test (one assertion per test)
• watch it fail (compilation errors count)
• make the test pass doing the simplest thing that will possibly work
• refactor to remove duplication
• repeat

Refactoring

Improving the structure of code without changing its behavior

• run all of the tests
  • they all must pass
• make a change
• run all of the tests
  • they all must pass

• Must be green (passing all tests) before refactoring. Comment out a failing test to get green if you must.
• Refactoring should never take you into the red (failing tests).

Mock Objects

• mocha can do mock objects in test/unit; rspec has its own mock objects