A technique for building software that guides software development by writing tests. This is the philosophy and state of mind that a developer should change and start following TDD

1. Test Driven
Development (TDD)
A technique for building software that guides
software development by writing tests.

2. About Me!
A Geek at heart.
Technology enthusiast
a haPHPy’er
A DevOps!
... actually a Fullstack Engineer
@vijaykumbhar
vijay.kumbhar
https://github.com/kvijay
Vijay Kumbhar

3. Agile Manifesto : Principles
● Continuous Delivery
● Love’s Changing Requirements
● Frequent Shippable Deliveries
● Involve everyone :)
● Frequent Communication
● Moto "A working software”
● Continuous attention to tech excellence and good design
● Simplicity is essential (DRY/SOLID)
● Self organizing teams
● Periodic Retrospective
“inspect-and-adapt” approach to development

4. Quotes
The act of writing unit test is more an act of design than verification
- by Robert C Martin aka Uncle Bob
Walking on water and developing software from a specification are
both easy if both are frozen
- By Edward V. Berard
Whenever you are tempted to type something into a print statement or
a debugger expression, write it as a test instead.
- By Martin Fowler
No process in this world is the best in all cases

5. Traditional Development Approach
Problem with this is...
● Complete manual intervention.
● Needs more focus and more energy.
Contd...
● We pick a requirement
● We write a code, create database ….
● Test the code
● If pass then starts with new features
● If fails starts from issues / modifying
code and test them again

6. Traditional Development Approach
When any issue/bug found in the application…
● Dissect code in and out.
● Takes more effort (Think of Legacy Code with 100000 LOC)
● It’s scaffolding exercise
● Setting up break points
● Monitoring temporary variables
● Having log statements in place, etc...
● Hard to maintain the code
● Need precise documentation or commenting in the code.
Hard Exercise ?

7. Who is the life Saver??

8. Getting Right Thought Process
Time, Cost, Quality, Extendibility, Readability,
Understandability

9. Change In Thought Process
Time, Cost, Quality, Extendibility, Readability,
Understandability
Mindblockers
● Big learning curve
● Need lots of time
● Affect the cost
In Reality
● Future : Cut down impact analysis and QA time.
● Long Goal : Reduces cost and time
● Improved Code quality
● Code is more readable & understandable.
● Fail early to succeed sooner

10. TDD Mantra
Red, Green, Refactor - the TDD mantra
● Red - write little test that doesn't
work
● Green - make test work as quickly
as possible, committing whatever
sins necessary in the process
● Refactor - eliminate all of the
duplication created in merely
getting the test to work
● Repeat

11. TDD Approach

12. TDD Approach
● Quickly add a test - just enough code to fail test.
● Run the tests - Run the test-suite to ensure the test fails.
● Update the code - Update your functional code to ensure new test passes.
● Re-run tests - Re-run the test-suite & keep updating the functional code
until test passes
● Refactor - The code and design to make the design as simple as possible
and remove any possible duplication and move on.
● **Repeat - Repeat the process again 1 to 5..

13. TDD Benefits
● Shorten the feedback cycle
● Provide detailed (executable) specification
● Promotes quality code with the constant refactoring
● Smells bad implementation
● In Minutes get fine grained and concrete feedback
● It lets your teammates count on you, and so can you on them.

14. Legacy Software dev. and testing
● Mostly follows the waterfall/big-ban process
● Very little emphasis on unit testing by developers
● Tests are almost developed as an afterthought
● Tests are mostly manual
● Huge emphasis on QA team
● Delivering the quality software on time and within budget is
almost accidental.

15. Myths about TDD
● Myth - TDD should be used in small projects involving enough team force but
won’t scale for large projects involving hundreds of people..
● Answer - Not True
- kent Beck worked on a pure TDD project developed in Smalltalk.
- 4 years and 40 man year of effort resulting in 250k lines of functional code
and 250k lines of test code.
- 4000 test cases run under 20 mins
- Full suite runs several times in a day

16. Ideal qualities of Unit tests
● Decisive
● Valid
● Complete
● Repeatable
● Isolated
● Automated

17. Why TDD?
If it’s worth building, it’s worth testing.
If its not worth testing, why are you
wasting your time working on it?
- Scott Ambler

18. Thank You!
@webonise weboniselab