Test Driven Development Methodology and Philosophy

Test Driven Development Methodology and Philosophy

• 1.
  Test Driven Development (TDD) Atechnique for building software that guides software development by writing tests.
• 2.
  About Me! A Geekat 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 ofwriting 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 Problemwith 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 Whenany 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 thelife Saver??
• 8.
  Getting Right ThoughtProcess Time, Cost, Quality, Extendibility, Readability, Understandability
• 9.
  Change In ThoughtProcess 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 ● Quicklyadd 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 ● Shortenthe 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 ofUnit tests ● Decisive ● Valid ● Complete ● Repeatable ● Isolated ● Automated
• 17.
  Why TDD? If it’sworth 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