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 18. First Steps to xUnit

Driving a testing tool using the testing tool itself to run the tests may seem a bit like performing brain surgery on yourself. (“Don't touch those motor centers—oh, too bad, game over.”) It will get weird from time to time. However, the logic of the testing framework is more complicated than the wimpy money example of Part I. You can read Part II as a step toward test-driven development of “real” software. You can read it as a computer-sciency exercise in self-referential programming.

First, we need to be able to create a test case and run a test method. For example: TestCase("testMethod").run(). We have a bootstrap problem: we are writing test cases to test a framework that we will be using to write the test cases. ...

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