1.
A Brief Introduction to Test-
Driven Development
Shawn M. Jones

2.
Who am I?
• Graduated ODU in 1999 with BS in Computer
Science
• Currently working on Master’s Degree in
Computer Science
• Worked for Department of Navy since 1997:
– Web Development
– System Administration
– Information Assurance (Computer Security)
– Requirements Analysis
– Application Development/Build Management
– Never worked in QA or IV&V

3.
Sources for this Presentation
• Beck, K. (2003). Test-Driven Development By Example. Boston:
Addison-Wesley.
• Fowler, Martin. Refactoring. http://martinfowler.com/refactoring/
• Osherove, R. (2012). “Write Maintainable Unit Tests That Will Save
You Time and Tears”. MSDN Magazine.
http://msdn.microsoft.com/en-us/magazine/cc163665.aspx
• (2012) Cunningham & Cunningham.
http://c2.com/cgi/wiki?TestDrivenDevelopment
• Personal Experience

4.
What do you know about automated
testing?

5.
Why You Should Care About
Automated Testing
• Automated testing allows you to check quickly
if you have changed how the code behaves.
• Automated testing provides other developers
an idea of how your functions/classes/libraries
are intended to be used.
• Without automated tests, how do you know
your code actually does what you intended?
How much confidence do you have in it?

6.
What do you know about TDD?
• TDD = Test Driven Development
• What else do you know?

7.
Tools for TDD
• Testing framework:
– JUnit (for Java)
– NUnit (for .NET)
– Unittest (for Python)
– Roll your own, if necessary
• To-Do List
• Software Project

8.
The Rhythm of Test-Driven
Development (TDD)
1. Quickly add a test.
2. Run all tests and see the new one fail.
3. Make a little change.
4. Run all tests and see them all succeed.
5. Refactor to remove duplication.

9.
The Rhythm of Test-Driven
Development (TDD)
Quickly add
a test
Run all tests
and see the
new one fail
Make a
little change
Run all tests
and see
them all
succeed
Refactor to
remove
duplication

10.
1. Quickly add a test
• Write the test before you write the code.
• This is hard for most of us, because we want
to solve the functionality problem now.
• Think about how to best use the target code.
How do you want to call that code?

11.
2. Run all tests and see the new one
fail
• Run the test, even if there is no target code for
it yet.
• Failure is the expected behavior, it provides a
known good starting point.
• What do you do if it passes when it shouldn’t?
– There’s no target code yet, why is it passing?
– Look at the test, is it a good test?

12.
3. Make a little change
• Now you can write the target code to pass the
test.
• We’re just focusing on the target code for this
existing automated test.
• Anything else you can think of should be
added to your to-do list.

13.
4. Run all tests and see them all
succeed
• Now you know that your code does what you
wanted and you have a way to prove it in the
future.
• If the code doesn’t pass the test, go fix it and
come back to this step.
• Once it works, you have confidence in the
code that you wrote.

14.
5. Refactor to remove duplication
• Refactoring – “a disciplined technique for
restructuring an existing body of code, altering its
internal structure without changing its external
behavior”
– Martin Fowler
• Removing duplication ensures that future tests
require fewer changes in the code, limiting
dependency between modules (loosely coupled).

15.
Why You Should Care About TDD
• TDD is not really just a testing strategy, it is a
design strategy.
• Code with well-written tests tends to be more
modular, loosely coupled, and easier to
incorporate into the application.
– This makes the code easier to maintain
– It also makes the code more understandable to
others

16.
Why You Should Care About Better
Code
• Remember, you will have to live with your
code
• Six months from now you will remember far
less about how it works, but you are still the
expert for your code
• Your coworkers will appreciate you more;
they have to live with your code, too

17.
Excuses for not using TDD
• “No automated testing framework exists for the
language/API/etc. in use”
• “Our application is mostly configuration files,
with no real code.”
• “We’re just writing scripts, not real code”
• “TDD is only for classes. My code has no classes.”
• “I’m a developer, not a tester.”
• “Do you want us to produce functionality or tests?”
• “The existing application has no automated tests.”

18.
When not to use TDD?
• Research for a new language/API/framework
where you will throw away all of your research
code.
• The language/OS has some construct that
cannot be evaluated by an automated test
(e.g. Console object in Java)
• You don’t have the hardware for testing the
given requirement.

19.
Issues with TDD
• Tests are additional code that must be
maintained with the code
• User interfaces can be tested, but change
often (use patterns such as MVC in order to
limit how much code ends up in the UI)
• TDD requires management support;
management may not believe testing is
worthwhile

20.
Other issues with TDD
• Use of TDD may cause the organization to
believe other testing (functional, user
experience, etc.) is not necessary
• The tests are only as good as the developer
who wrote them (e.g. a developer unaware of
SQL injection attacks will not check for them)

21.
Questions?