Upgrade to Pro — share decks privately, control downloads, hide ads and more …

9 ways to test your spaghetti code

9 ways to test your spaghetti code

“Test the legacy code as well” has been a mantra for many years now. But how do you actually do that? When stuck with tangled legacy-spaghetti, it may be hard to see the way out. The path from struggling with your spaghetti into doing TDD is shorter than you think.

It's so easy to say that you should test code as you change it, now matter how legacy, but in a real-world project, you need to know some tools and techniques to be able to do that. This talk will give you concrete techniques, along with a way of thinking to figure out those tricks you need in your code base.

I came into a project where writing tests was considered really hard and time consuming, and TDD was “impossible”. I did it anyway, and I want to share what we did and what we've learned from it.

Given at https://javaday.istanbul/

52482b46b478633a2b766bbf36916fd3?s=128

Mads Opheim

March 16, 2019
Tweet

Transcript

  1. JavaDay Istanbul 9 ways to test your spaghetti code Mads

    Opheim @MadsOpheim
  2. Goal of this talk: You’ll be enabled to test your

    spaghetti code 2
  3. What is spaghetti code? 3

  4. I don’t like testing 4

  5. I don’t like testing manual verification 5

  6. Precondition: You are creative The computer is not 6

  7. Don’t Repeat Yourself 7

  8. The 9 ways 8

  9. 9 1. Test all or Test small

  10. 10 2. Set your dependencies

  11. 11

  12. Use interfaces 12

  13. 13

  14. Singletons 14

  15. 3. Package-protect problematic parts 15

  16. 16

  17. 4. Consider removing final or static 17

  18. In general: untangling 18

  19. You’re not as smart as you think 19

  20. Well-designed code is testable code 20

  21. Your test code should be simple 21

  22. Do simple refactorings to get your code under test 22

  23. Use characterization tests 23

  24. 24 5. Help your team

  25. 6. Run your tests - and care 25

  26. 7. Feature toggles 26

  27. 8. One class can have several test classes 27

  28. One mile at a time 28

  29. Refactor in separate commits 29

  30. 9. Test-driven development 30

  31. Test-driven spaghetti 31

  32. TDD on legacy code in practice 32

  33. Get started with TDD 33

  34. Tip 10, 11 and onwards 34

  35. Beware of limiting beliefs 35

  36. You’ll forget things 36

  37. You’ll do stupid things - and that’s ok 37

  38. You get what you measure 38

  39. Real or fake data? 39

  40. Be consistent 40

  41. Give me more @lisacrispin, @lisihocke, @techgirl1908, @maaretp... 41

  42. Bonustrack: The technical domain? 42

  43. Split technical tests from functional tests 43

  44. 44 The Deadline For Kunngjøring Is Four Weeks()

  45. 45 Properties For Namsmann Mainly Follow The Same Rules as

    Hovedstevnevitne()
  46. Key takeaways 46 1. Good code design improves testability 2.

    TDD on spaghetti code: TDD + test spaghetti code 3. Write tests for you legacy code - you can do it!
  47. Thank you! 47 @MadsOpheim mads.opheim@computas.com