Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Test Driven Development – TDD | Per Sundvall | LTG-43/DTG-7

349 views

Published on

Presentation hållen vid samarrangemanget Lean Tribe Gathering 43 och Dev Tribe Gathering 7 i Göteborg 9 maj 2017.

Published in: Software
  • Be the first to comment

  • Be the first to like this

Test Driven Development – TDD | Per Sundvall | LTG-43/DTG-7

  1. 1. Test Driven Development - TDD
  2. 2. What is the worst factor that jeopardize quality?
  3. 3. • It stops new team members from changing things because they don't understand the system, and it stops experienced people changing things because they understand it all too well. Fear is the mind-killer.
  4. 4. • The primary goal of unit testing is to prevent fault, not to find them. • Finding the error (or errors) in the integrated module is much more complicated than first isolating the units, testing each, then integrating them and testing the whole. • Good unit test are those that: • Runs fast. • Helps us to localize problems. • Can be used as a specification of the unit. What is unit test?
  5. 5. Approximate distribution of faults Fault of omission Low level faults ⅓ ⅓ ⅓ More efficient and focused testing gives more output for the same effort and with that faster time to market and higher quality.
  6. 6. NO Unit Test
  7. 7. Test-Driven Development (TDD) is a technique for building software that guides software development by writing tests. It was developed by by Kent Beck in the late 1990's as part of Extreme Programming. In essence you follow three simple steps repeatedly. TDD - Martin Fowler
  8. 8. • Drives sound architecture and design (Clean Code) – it’s more difficult to write tests otherwise. • Easier to understand the behavior of the code – makes it easier to spot missing behaviors. (~40% of failures are fault of omission). • Clear view of how far development has proceeded – less stress. • Easier to refactor the code – safety net for change. Main points of TDD
  9. 9. • “The most common way that I hear to screw up TDD is neglecting the third step. Refactoring the code to keep it clean is a key part of the process, otherwise you just end up with a messy aggregation of code fragments. (At least these will have tests, so it's a less painful result than most failures of design.)” TDD - Martin Fowler
  10. 10. • TDD give you the confidence to do long-term development because with component tests in place, you know that your foundation code is dependable. • TDD give you the confidence to refactor your code to make it cleaner and more efficient. • TDD also save you time because component tests help prevent regression faults from being introduced and released. • Another advantage is that component tests provide excellent implicit documentation because they show exactly how the code is designed to be used. Value of TDD
  11. 11. • Case studies were conducted with three development teams at Microsoft and one at IBM that have adopted TDD. The results of the case studies indicate that the pre-release defect density of the four products decreased between 40% and 90% relative to similar projects that did not use the TDD practice. Subjectively, the teams experienced a 15–35% increase in initial development time after adopting TDD. • From an efficacy perspective this increase in development time is offset by the by the reduced maintenance costs due to the improvement in quality. TDD Benefit
  12. 12. VALUE OF TDD “On questions on programmer productivity, an overwhelming majority of the developers believed that TDD approach facilitates better requirements understanding (87.5%) and reduces debugging effort (95.8%).” - An Initial Investigation of Test Driven Development in Industry, Boby George, Laurie Williams
  13. 13. • “When we need to change code, we should have tests in place. To put tests in place, we often have to change the code” – Micael C. Feathers Legacy Code Dilemma
  14. 14. • Drives sound architecture and design (Clean Code) – it’s difficult to write tests otherwise. • Easier to understand the behavior of the code – makes it easier to spot missing behaviors. (~40% of failures are fault of omission). • Clear view of how far development has proceeded – less stress. • Easier to refactor the code – safety net for change. Main points of TDD
  15. 15. › Instead of 1.Do a lot of changes 2.Fix a lot of unit tests 3.Repeat › Try 1.Plan a small change 2.Change the relevant unit test(s) 3.Change relevant code 4.Repeat TDD Maintance
  16. 16. › Writing test code normally takes less effort then implementing. › It like stating “that no three positive integers a, b, and c can satisfy the equation an + bn = cn for any integer value of n” – it took 358 years and a 150+ pages of proof. › “Now when I test drive, I start with writing a test which usually takes me few minutes (about 5 minutes) to write. The test represents my scenario. I then start implementing the code to make the scenario pass, and the implementation usually takes me a lot longer (about 50 minutes).” - Miško Hevery, Google TDD Effort
  17. 17. • Not providing sufficient training, education, and mentoring • Not using a Mocking Framework • Writing Tests Retrospectively • Line coverage obsession • Completely reducing initial modeling • Completely reducing parallel independent testing Common TDD Mistakes

×