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/

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
12. Use interfaces 12
14. Singletons 14
15. 3. Package-protect problematic parts 15
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