Test Driven Development Methodology and Philosophy


Published on

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

Published in: Software, Technology

Test Driven Development Methodology and Philosophy

  1. 1. Test Driven Development (TDD) A technique for building software that guides software development by writing tests.
  2. 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. 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. 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. 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. 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. 7. Who is the life Saver??
  8. 8. Getting Right Thought Process Time, Cost, Quality, Extendibility, Readability, Understandability
  9. 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. 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. 11. TDD Approach
  12. 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. 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. 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. 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. 16. Ideal qualities of Unit tests ● Decisive ● Valid ● Complete ● Repeatable ● Isolated ● Automated
  17. 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. 18. Thank You! @webonise weboniselab