Test Driven Development (TDD) is a software development process where requirements are transformed into specific test cases that guide the writing of code. TDD involves a repetitive cycle of writing a failing test, creating code to pass the test, and then refactoring the code while maintaining tests that serve as documentation. Key aspects include a solid understanding of programming languages, unit testing frameworks, and a focus on clean code and design principles.

1. TEST DRIVEN DEVELOPMENT
1
RAJESH KUMAR

2. DEFINITION
 Software Development Process that relies on the repetition of a
very short development cycle. Requirements are turned into very
specific test cases, then the software is improved to pass tests.
 Tests come first
 Its repetitive process
 Tests reflect the requirements
 Tests determine what code is to be written
2

3. TECHNIQUE
1. Write a single failing test
2. Run the failing test
3. Write minimal code that fixes the test
4. Run the test again
5. Refactor the code
6. Repeat
3

4. REFACTORING
 Rewriting already-working code
 Elimination of duplicate code
 DRY, Single Responsibility etc.
 Simplify code
 The intent of code should be clear
 Follow some accepted practices e.g.
 Design Patterns, Design Principles, Clean coding etc.
4

5. WHAT YOU SHOULD KNOW?
 A Programming Language
 Java, C#
 A Unit Testing Framework
 jUnit, TestNG, nUnit etc.
 Mocking
 JMock, Mockito, Moq, RhinoMocks
 Refactoring
 Framework related tools (Not necessary but helpful)
 Spring Testing, DbUnit, In-memory DB, Embedded Server
5

6. HOW TO LEARN TDD
 There are many books and articles on tools and techniques
 Test Driven Development, by Kent Beck is a good for starting
 Mostly, learn by doing
 Helps, if you learn by doing it with somebody that already knows how
 If you are writing unit test cases with mocking
 then you are halfway there
 but in reverse 
6

7. SCENARIO (EXISTING CODE)
 Break a change into small parts
 Select first change to be made
 Implement test and code for that change (The Technique)
 Run all tests
 Select next change and repeat
7

8. CHARACTERISTICS OF A TDD PROJECT
 Results in “clean code that works”
 A white-box unit-testing mechanism
 Tests work as an automated regression test suite
 Changes are easy to incorporate
 Bugs can be easily isolated
 Refactoring is easy
 Tests work as documentation of system
 Design evolution happens as you go along
8

9. WHY DOES TDD WORK?
 Encourages “divide-and-conquer”.
 Programmers are never scared to make a change that might
“break” the system.
 Leads the programmers to think about details they otherwise
would not think about.
 The testing time that is often “squeezed out of the end of a
traditional development cycle” cannot be squeezed out.
9

10. RULES FOR DEVELOPERS
 Unit Testing is not separate or lesser from coding
 Start as simply or as small as possible
 But start 
 Write new code only if a test is failing
 Refactor code ruthlessly
 Make tests fast, it encourages programmers to run them all
regularly
10

11. QUESTIONS?
11

12. DESIGN NOT NECESSARY?
IS IT REALLY TRUE?
12