Test Driven Development

What is test Driven Development?

1. Test Driven Development 1 Rajesh Kumar

2. Definition Software D evelopment P rocess 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 T ests determine what code is to be written 2

3. Technique Write a single failing test Run the failing test Write minimal code that fixes the test Run the test again Refactor t he code Repeat 3

4. R efactoring 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 L anguage Java, C# A Unit T esting F ramework 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