Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Test Driven Development

The jury is in! TDD works.

Terrence Truta

on 25 October 2012

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Test Driven Development

It's shorter than you think The Journey to Implementing Test Driven Development The jury is in!
The controversy over
GOTO is harmful
And TDD works.
- Robert Martin "Clean Code" Before we start any journey,
we should know why. 1. You may not write production code until you have written a failing unit test The Three Steps of TDD The Three Steps of TDD Good Tests... Bowling Demo 1. Improves Code Quality
Allows Fearless Refactoring and Cleaning
Improves Design
Increases Cohesion
Reduces Coupling
Reduces Duplication
Increases Clarity Why Test Driven Development Code that is easy to test naturally has these qualities. What is the best way to get code that is easy to test? Write the test first! Why Test Driven Development 2. Drives Emergent Design
Refactoring is the basis for OO design
Writing tests is really analysis
TDD (like Agile) mitigates the risk of waste by overdesign
Agile Methodology at the code level Why Test Driven Development 3. Unit Tests are the best form of documentation
Never out of date
Formal (executable)
Understood by Developers
Tells Narrative of Design
"Professional" Unit Tests are Documents First and Tests Second Writing your tests first First, write a failing test
(not compiling is failing) Do not write more production code than is sufficient to pass the currently failing test. Repeat until you are finished... The green bar is your friend. Add another behavior to get a red bar. Then write just enough code to fix it. Ideally the cycle should be about 30 seconds. The appropriate design will emerge out of necessity.
For example, scoring a spare:
The score for a spare is 10 plus the number of pins the player knocks down on the next throw.
This creates the need for the score to be independent of the Frame
We need a Game Object The scoreForFrame method is a little cryptic. Let's Refactor. It still works! Now we are ready to write the test for scoring a spare. Write Production Code... Voila, coding is fun again! 2000 1800 1900 Refactor portions of the Frame object into the Game object. Add a method to get a score for any frame... Fearless Refactoring Emergent Design PATS Demo Write a test for an existing class. The Exception isn't thrown, it is put into the file contents. Interesting. Unit tests should not rely on any external resources (e.g. files, VPN, databases, etc.). Use Before and After methods to set up your test so they can be run in any environment. Mock example using EasyMock Ironically, Spring with XML Configuration increases dependency for Unit tests. Need to jump through some hoops to get this to work. If we upgrade to Spring 3.0 we can use Java Config instead. 1. Test Behavior - not methods
2. Use as many Asserts as necessary
3. Repeatable Tests
Don't rely on external state
Use Mock Objects
4. Small and Fast
5. Self-validating 1. Will always fail for the reason it was intended to

2. Never fail for any other reason

3. No other test should fail for the same reason. 2. You may not write more of a unit test than is sufficient to fail, and not compiling is failing
3. You may not write more production code than is sufficient to pass the current failing test The Three Steps of TDD Final Thoughts Best Practices Get it Correct Before Optimizing Once you have all of your tests, you can try some radical things to optimize the performance. Mobile Demo Create a Mock Communicator Object to get the test to compile/pass Tests written before code tend to be more comprehensive and not just "Happy Path" From Test-Driven iOS Development
by Graham Lee Method to overwrite specific GAC entries in your tests. From Agile Software Development, Principles, Patterns, and Practices
by Robert Martin. References Complete TDD Bowling Demo - http://www.objectmentor.com/resources/articles/xpepisode.htm
Clean Code (Chapter 9) by Robert Martin - http://techbus.safaribooksonline.com/book/software-engineering-and-development/agile-development/9780136083238/unit-tests/ch09
The Clean Coder (Chapter 5) by Robert Martin - http://techbus.safaribooksonline.com/book/programming/9780132542913/test-driven-development/ch05
Niel Ford’s Presentation on TDD - http://techbus.safaribooksonline.com/9781449314439
Test Driven iOS Development by Graham Lee - http://techbus.safaribooksonline.com/book/software-engineering-and-development/software-testing/9780132764049
Full transcript