Introducing tests... To a legacy codebase 

Summary Introducing tests… ● To you ● To a legacy codebase ● To your team ● To the shipping pipeline 

Introducing tests... To you “Program testing can be used to show the presence of bugs, but never to show their absence.” ~ Edsger Dijkstra 

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. 

What is a test ? if (false) { throw(); } Independent program Runs against our code Double entry bookkeeping Applied to programming Introducing tests to you 

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 

Who is responsible for writing tests ? Not the C level. Not the project managers. Not the QA. We are. 

Kinds of tests: Expectations Introducing tests to you https://martinfowler.com/articles/practical-test-pyramid.html Unit Tests Integration Tests End to end Tests 

Kinds of tests: Reality Introducing tests to you https://watirmelon.blog/testing-pyramids/ Unit Tests Integration Tests End to end Tests Manual tests 

Introducing tests to you ● What is a test ? ● Why test ? ● Who is responsible for tests ? ● Different kinds of tests ? 

Introducing tests... To a legacy codebase 

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 

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. 

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.) 

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. 

Introducing tests to a legacy codebase The Tell don’t ask Principle : Before https://martinfowler.com/bliki/TellDontAsk.html 

Introducing tests to a legacy codebase The Tell don’t ask Principle : After https://martinfowler.com/bliki/TellDontAsk.html 

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 

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 

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 

Introducing tests to a Legacy codebase ● Where to start ? ● TDD ● CQS ● SRP ● TDA https://android.jlelse.eu/solid-principles-the-definitive-guide-75e30a284dea 

Introducing tests... To your team 

Automation ! Introducing tests to a team 

Metrics: First Introducing tests to a team Gotta start somewhere huh ? 

Metrics: Asking the team to write tests Introducing tests to a team 

Metrics: Something interesting happened Introducing tests to a team 

Metrics: Something interesting happened Introducing tests to a team 

Metrics: Something interesting happened Introducing tests to a team You get coverage ! And you get coverage ! Every file gets coverage ! 

No content

Pair programming ! A few caveats: ● Keyboard and layout ● IDE Setup ● Remote ● Live share plugins https://www.commitstrip.com Introducing tests to a team 

Introducing tests to a team ● Automation ● Metrics ● Pair programming Agile XP http://www.extremeprogramming.org/ 

Introducing tests... To the production pipeline 

Automate the CI / CD Introducing tests to the production pipeline 

Integrate tests to the CI Introducing tests to the production pipeline 

Make sure no artefact is created if tests fail. Introducing tests to the production pipeline https://github.com/codedance/Retaliation 

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 

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 

Thank you ! 

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 

Thank you ! Jeremy Lempereur @o0Ignition0o Let’s share knowledge on the Polymorphic Slack channel : https://bit.ly/2HbNg6G