You are previewing Test Driven Development: By Example.

Test Driven Development: By Example

Cover of Test Driven Development: By Example by Kent Beck Published by Addison-Wesley Professional
  1. Copyright
    1. Dedication
  2. The Addison-Wesley Signature Series
    1. The Addison-Wesley Signature Series
      1. Signers: Kent Beck and Martin Fowler
  3. Preface
    1. Courage
  4. Acknowledgments
  5. Introduction
  6. I. The Money Example
    1. 1. Multi-Currency Money
    2. 2. Degenerate Objects
    3. 3. Equality for All
    4. 4. Privacy
    5. 5. Franc-ly Speaking
    6. 6. Equality for All, Redux
    7. 7. Apples and Oranges
    8. 8. Makin' Objects
    9. 9. Times We're Livin' In
    10. 10. Interesting Times
    11. 11. The Root of All Evil
    12. 12. Addition, Finally
    13. 13. Make It
    14. 14. Change
    15. 15. Mixed Currencies
    16. 16. Abstraction, Finally
    17. 17. Money Retrospective
      1. What's Next?
      2. Metaphor
      3. JUnit Usage
      4. Code Metrics
      5. Process
      6. Test Quality
      7. One Last Review
  7. II. The xUnit Example
    1. 18. First Steps to xUnit
    2. 19. Set the Table
    3. 20. Cleaning Up After
    4. 21. Counting
    5. 22. Dealing with Failure
    6. 23. How Suite It Is
    7. 24. xUnit Retrospective
  8. III. Patterns for Test-Driven Development
    1. 25. Test-Driven Development Patterns
      1. Test (noun)
      2. Isolated Test
      3. Test List
      4. Test First
      5. Assert First
      6. Test Data
      7. Evident Data
    2. 26. Red Bar Patterns
      1. One Step Test
      2. Starter Test
      3. Explanation Test
      4. Learning Test
      5. Another Test
      6. Regression Test
      7. Break
      8. Do Over
      9. Cheap Desk, Nice Chair
    3. 27. Testing Patterns
      1. Child Test
      2. Mock Object
      3. Self Shunt
      4. Log String
      5. Crash Test Dummy
      6. Broken Test
      7. Clean Check-in
    4. 28. Green Bar Patterns
      1. Fake It ('Til You Make It)
      2. Triangulate
      3. Obvious Implementation
      4. One to Many
    5. 29. xUnit Patterns
      1. Assertion
      2. Fixture
      3. External Fixture
      4. Test Method
      5. Exception Test
      6. All Tests
    6. 30. Design Patterns
      1. Command
      2. Value Object
      3. Null Object
      4. Template Method
      5. Pluggable Object
      6. Pluggable Selector
      7. Factory Method
      8. Imposter
      9. Composite
      10. Collecting Parameter
      11. Singleton
    7. 31. Refactoring
      1. Reconcile Differences
      2. Isolate Change
      3. Migrate Data
      4. Extract Method
      5. Inline Method
      6. Extract Interface
      7. Move Method
      8. Method Object
      9. Add Parameter
      10. Method Parameter to Constructor Parameter
    8. 32. Mastering TDD
      1. How large should your steps be?
      2. What don't you have to test?
      3. How do you know if you have good tests?
      4. How does TDD lead to frameworks?
      5. How much feedback do you need?
      6. When should you delete tests?
      7. How do the programming language and environment influence TDD?
      8. Can you test drive enormous systems?
      9. Can you drive development with application-level tests?
      10. How do you switch to TDD midstream?
      11. Who is TDD intended for?
      12. Is TDD sensitive to initial conditions?
      13. How does TDD relate to patterns?
      14. Why does TDD work?
      15. What's with the name?
      16. How does TDD relate to the practices of Extreme Programming?
      17. Darach's Challenge
    9. I. Influence Diagrams
      1. Feedback
    10. II. Fibonacci
    11. Afterword
O'Reilly logo

Chapter 28. Green Bar Patterns

Once you have a broken test, you need to fix it. If you treat a red bar as a condition to be fixed as quickly as possible, then you will discover that you can get to green quickly. Use these patterns to make the code pass (even if the result isn't something you want to live with for even an hour).

Fake It ('Til You Make It)

What is your first implementation once you have a broken test? Return a constant. Once you have the test running, gradually transform the constant into an expression using variables.

A simple example occurred in our implementation of xUnit:

return "1 run, 0 failed"

became:

return "%d run, 0 failed" % self.runCount

became:

return "%d run, %d failed" % (self.runCount , self failureCount)

Fake It is ...

The best content for your career. Discover unlimited learning on demand for around $1/day.