TDD For The Curious

A lot has been said about TDD with the rise of the agile software development movement. However, it’s still confusing for both novice and experienced programmers. In my talk,
I’ll explain what TDD is all about, why we at Wix believe it’s beneficial (and crucial!), and how you can get started applying TDD in your teams and projects.

Transcript

1. What, Why, How TDD For The Curious Amitay Horwitz / Wix amitayhorwitz amitayh @amitayh amitayh@wix.com
2. Amitay Horwitz ~2 years developing Scala @ Wix’s server group
3. What? 01
4. • TDD is not (only) about testing • TDD is not a waste of time (in the long run) • TDD != no design Common misconceptions
5. TDD (Test Driven Development/Design) is a discipline for writing software, in which automated tests are written before the production code is written So what IS TDD?
6. When practicing TDD it is forbidden to write a new line of code, unless it’s used to make a failing test pass! So what IS TDD?
7. The term was coined by Kent Beck, and relates to XP methodologies which started in the late 1990s So what IS TDD? https://media.simplecast.com/episode/image/11199/thumb_1441192692-artwork.jpg
8. Why? 02
9. BECAUSE WE SUCK
10. Real engineering...
11. http://www.hrreview.co.uk/wp-content/uploads/engineering300.gif
12. http://www.strongestinworld.com/wp-content/uploads/2016/01/Sutong-Bridge.jpg
13. And then there’s software engineering...
14. http://img.photobucket.com/albums/v13/foxbat/imagesstrongbridge.jpg
15. https://s-media-cache-ak0.pinimg.com/736x/37/26/94/3726944d00804dc83b064f6a893865ce.jpg
16. • Fewer defects in production • Short feedback loop • Easier to get new people working on a project • Tests as documentation / specification ◦ “Truth can only be found in one place: the code.” - Uncle Bob Martin • No fear of changes and refactoring = less code rot • And more... I can blab about...
17. But how cool is that this:
19. This was the QA process.
20. SERIOUSLY. If the tests pass - I ship it
21. How? 03
22. TDD 101
23. https://pbs.twimg.com/media/ClJ8jXpWEAAAZaZ.jpg
24. • Write a failing test that checks a specific part of functionality • You must run the test! If the test passes then there’s (probably) something wrong with the test • A test should contain one logical assertion about the system (test one thing only) • Given / when / then mindset Red
25. • Write the minimal amount of production code to make the failing test pass • Don’t try to implement the whole solution up-front - keep within the boundaries of the test • Make sure you don’t break other tests in the process. The rest of the test suite is your “safety net”, which allows you to make changes without fear Green
26. • Once the test passes, you can cleanup the code you wrote • Identify code duplication and extract to methods / classes • Identify common patterns and introduce abstractions • Keep the tests passing in the process • Tests are also code! Refactor the tests as well • Continue to next iteration Refactor
27. http://www.ministryoftesting.com/wp-content/uploads/2014/08/graphic_1.jpg.png
28. "viewed invoice" should { "have last viewed date" in { givenInvoiceWasSavedAndSent(invoice) givenInvoiceWasViewed(invoice, viewedAt = now) dao.getInvoices must contain(anInvoiceWithLastViewedDate(now)) } } What a typical test looks like (Specs²)
29. • What should / shouldn’t I test? • How do I test this thing? • Many confusing terms ◦ Unit tests, integration tests, end-to-end tests, component tests, acceptance tests, mocks, stubs, fakes, spikes, ATDD, BDD, ... But it’s hard to get started
30. Some terminology http://www.natpryce.com/articles/000772.html
31. Unit tests exercise individual objects or value types or small clusters of objects within in a single process Unit tests http://www.natpryce.com/articles/000772.html
32. Integration tests verify that implementation on an abstraction that we own integrates with some third-party package correctly Integration tests http://www.natpryce.com/articles/000772.html
33. System tests exercise the entire system end-to-end, driving the system through its published remote interfaces and user interface System / end-to-end tests http://www.natpryce.com/articles/000772.html
34. As demonstrated in “Growing Object Oriented Software, Guided By Test” by Steve Freeman and Nat Pryce We like outside-in TDD http://www.growing-object-oriented-software.com/cover.jpg
35. • Start from a failing end-to-end test ◦ Forces you to create the “walking skeleton” • Write code from the call site (wishful thinking) • Evolve your code by spotting the abstractions needed for solving your problems • Promotes YAGNI (You Ain’t Gonna Need It) Outside-in TDD
36. http://i.stack.imgur.com/FW1KG.jpg
37. http://fruzenshtein.com/wp-content/uploads/2015/11/place-of-unit-test-in-testing-pyramide.png
38. In a perfect world
39. Dealing with legacy code http://cookdiary.net/wp-content/uploads/images/Spaghetti_15818.jpg
40. • Add new functionality / features using TDD as much as you can. Untested code tends to be more coupled and harder to test • Try to write integration and end-to-end tests to verify the correctness of your software • When fixing bugs, try to first recreate them in some test • Once you feel confident enough, refactor out the problematic parts. You may never get to a state where everything is tested thoroughly Dealing with legacy code
41. • For basic testing all you need is def assert(assertion: Boolean) = { if (!assertion) throw new AssertionError } • But it’s really helpful to have advanced features ◦ Ability to run only parts of the test suite ◦ Custom composable matchers • Many choices - Specs² (Scala), JUnit (Java), NUnit (C#), Jasmine (JavaScript), Midje (Clojure), ... Use decent tooling
42. • TDD katas ◦ String calculator, bowling game, poker hands, FizzBuzz, prime factors, word wrap, natural sorting... ◦ Anything you want • Side projects ◦ https://github.com/amitayh/lispjs ◦ https://github.com/amitayh/scala-game-of-life ◦ https://github.com/amitayh/mano-machine-emulator ◦ https://github.com/amitayh/amd-compiler • Open source contributions Practice!
43. • Requires discipline • Requires practice • The whole team has to be committed - you can’t do TDD by yourself • After initial investment - allows you to move and react to changes much quickly TDD is an investment
44. http://10gjera.com/wp-content/uploads/2015/06/bigstock-man-comfortably-sleeping-in-hi-15694625.jpg
45. More resources GOOS - Steve Freeman, Nat Pryce Clean Code - Robert C. Martin Refactoring - Martin Fowler TDD By Example - Kent Beck
46. https://stylestalkerxo.files.wordpress.com/2014/07/1388816856725.png
47. This is where you are going to present your final words. This slide is not meant to have a lot of text. Thank You! Any Questions? amitayhorwitz amitayh @amitayh amitayh@wix.com