Introducing tests to a legacy codebase

We often get to read, hear introductions to tests and test driven development, starting from scratch, and it sometimes gets pretty confusing to go from a TDD fibonnaci example to your years old legacy codebase.

So today we want to turn it upside down, start with a big (did i hear someone say spaghetti code?) ball of mud / codebase, and figure out a way to progressively reclaim our codebase.

We will first figure out why we want to introduce tests, and learn how to convince managers and the business teams Testing is worth it.

We will then learn what kinds of tests we can add to our toolkit, and when they fit our needs.

We will then figure out where to start in real life (which means there is already a lot of code running in production, and any mistake can put us in serious trouble), and how to gain understanding over the codebase.

We will then talk about how to make if a team effort, because not any of this makes sense if a team member does not see any positive outcome, they won't want to invest time and efforts in tests, and there will be gaps in your the overall code quality.

Transcript

1. Introducing tests... To a legacy codebase
2. Summary Introducing tests… • To you • To a legacy codebase • To your team • To the shipping pipeline
3. Introducing tests... To you “Program testing can be used to show the presence of bugs, but never to show their absence.” ~ Edsger Dijkstra
4. Disclaimer The next slide contains code. The code is probably terrible in many ways. As I will see it again I will probably want to delete and rewrite it. Tests allow me to do so. Don’t get attached. THE NEXT SLIDE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
5. What is a test ? if (false) { throw(); } Independent program Runs against our code Double entry bookkeeping Applied to programming Introducing tests to you
6. Why test ? https://blog.pdark.de/2012/07/21/software-development-costs-bugfixing/ https://xbsoftware.com/blog/cost-bugs-software-testing/ Introducing tests to you The cost of bugs Assert that the program : • does not fail • won’t fail anymore • won’t fail again Write bug free code Spot bugs as early as possible
7. Who is responsible for writing tests ? Not the C level. Not the project managers. Not the QA. We are.
8. Kinds of tests: Expectations Introducing tests to you https://martinfowler.com/articles/practical-test-pyramid.html Unit Tests Integration Tests End to end Tests
9. Kinds of tests: Reality Introducing tests to you https://watirmelon.blog/testing-pyramids/ Unit Tests Integration Tests End to end Tests Manual tests
10. Introducing tests to you • What is a test ? • Why test ? • Who is responsible for tests ? • Different kinds of tests ?
11. Introducing tests... To a legacy codebase
12. Where to start ? Build a test harness: • Do not refactor anything yet • Call functions and capture the output • Write tests that assert you will keep the same output • Make sure they all pass Introducing tests to a legacy codebase
13. New Features / Bugs : TDD Introducing tests to a legacy codebase https://lucetzer.github.io/tdd-and-red-green-cycle/index.html Write a test. If the test already passes, no need to write code Make the suite pass as quick as possible. Refactor the code and the tests, while keeping the suite valid.
14. Start refactoring: Command/Query Separation Introducing tests to a legacy codebase https://martinfowler.com/bliki/CommandQuerySeparation.html Please watch Sandi Metz & Katrina Owen! Queries Commands Example car.getColor() engine.start() When called, output Return values Don’t return anything When called, create Nothing Side effects Tests must Assert return value Assert side effects Assert that other commands are sent Try to separate commands and queries as much as possible, but figure out when you can’t ! (Atomicity, queue.pop() etc.)
15. Disclaimer The next slide contains code. The code is probably terrible in many ways. As I will see it again I will probably want to delete and rewrite it. Tests allow me to do so. Don’t get attached. THE NEXT SLIDE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
16. Introducing tests to a legacy codebase The Tell don’t ask Principle : Before https://martinfowler.com/bliki/TellDontAsk.html
17. Introducing tests to a legacy codebase The Tell don’t ask Principle : After https://martinfowler.com/bliki/TellDontAsk.html
18. Introducing tests to a legacy codebase https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design The single responsibility principle: before
19. Introducing tests to a legacy codebase https://scotch.io/bar-talk/s-o-l-i-d-the-first-five-principles-of-object-oriented-design The single responsibility principle: after
20. Finish refactoring By now your tests cover the harness • Harness tests are passing • Acceptance tests are passing • Code is readable • App works as intended Delete the harness ! Introducing tests to a legacy codebase
21. Introducing tests to a Legacy codebase • Where to start ? • TDD • CQS • SRP • TDA https://android.jlelse.eu/solid-principles-the-definitive-guide-75e30a284dea
22. Introducing tests... To your team
23. Automation ! Introducing tests to a team
24. Metrics: First Introducing tests to a team Gotta start somewhere huh ?
25. Metrics: Asking the team to write tests Introducing tests to a team
26. Metrics: Something interesting happened Introducing tests to a team
27. Metrics: Something interesting happened Introducing tests to a team
28. Metrics: Something interesting happened Introducing tests to a team You get coverage ! And you get coverage ! Every file gets coverage !
30. Pair programming ! A few caveats: • Keyboard and layout • IDE Setup • Remote • Live share plugins https://www.commitstrip.com Introducing tests to a team
31. Introducing tests to a team • Automation • Metrics • Pair programming Agile XP http://www.extremeprogramming.org/
32. Introducing tests... To the production pipeline
33. Automate the CI / CD Introducing tests to the production pipeline
34. Integrate tests to the CI Introducing tests to the production pipeline
35. Make sure no artefact is created if tests fail. Introducing tests to the production pipeline https://github.com/codedance/Retaliation
36. Introducing tests to the production pipeline • Automate the CI/CD • Add tests (and lints) to the pipeline • Do not build artefacts with defects • Make sure any team member knows how to ship code https://android.jlelse.eu/solid-principles-the-definitive-guide-75e30a284dea
37. Build a trust environment to your org • Pair programming creates a learning / sharing environment • An automated CI/CD pipeline builds team confidence • Tests allow you to ship code faster, with less bugs • Pragmatism allow members to iterate / improve the process Conclusion
38. Thank you !
39. Awesome links https://martinfowler.com - Martin Fowler blog (All of it, seriously) https://blog.cleancoder.com/ - Robert “Uncle Bob” C Martin’s blog https://medium.com/@kentbeck_7670 - Kent Beck Medium blog https://www.youtube.com/watch?v=URSWYvyc42M Sandy Metz - The magic tricks of testing https://vimeo.com/68730418 Katrina Owen - 467 tests, 0 failures, 0 confidence - Railsberry 2013
40. Thank you ! Jeremy Lempereur @o0Ignition0o Let’s share knowledge on the Polymorphic Slack channel : https://bit.ly/2HbNg6G