Tweet
Tweet

Slide 1

Slide 1 text

What, Why, How TDD For The Curious Amitay Horwitz / Wix amitayhorwitz amitayh @amitayh [email protected]

Slide 2

Slide 2 text

Amitay Horwitz ~2 years developing Scala @ Wix’s server group

Slide 3

Slide 3 text

What? 01

Slide 4

Slide 4 text

● TDD is not (only) about testing ● TDD is not a waste of time (in the long run) ● TDD != no design Common misconceptions

Slide 5

Slide 5 text

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?

Slide 6

Slide 6 text

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?

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

Why? 02

Slide 9

Slide 9 text

BECAUSE WE SUCK

Slide 10

Slide 10 text

Real engineering...

Slide 11

Slide 11 text

http://www.hrreview.co.uk/wp-content/uploads/engineering300.gif

Slide 12

Slide 12 text

http://www.strongestinworld.com/wp-content/uploads/2016/01/Sutong-Bridge.jpg

Slide 13

Slide 13 text

And then there’s software engineering...

Slide 14

Slide 14 text

http://img.photobucket.com/albums/v13/foxbat/imagesstrongbridge.jpg

Slide 15

Slide 15 text

https://s-media-cache-ak0.pinimg.com/736x/37/26/94/3726944d00804dc83b064f6a893865ce.jpg

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

But how cool is that this:

Slide 18

Slide 18 text

No content

Slide 19

Slide 19 text

This was the QA process.

Slide 20

Slide 20 text

SERIOUSLY. If the tests pass - I ship it

Slide 21

Slide 21 text

How? 03

Slide 22

Slide 22 text

TDD 101

Slide 23

Slide 23 text

https://pbs.twimg.com/media/ClJ8jXpWEAAAZaZ.jpg

Slide 24

Slide 24 text

● 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

Slide 25

Slide 25 text

● 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

Slide 26

Slide 26 text

● 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

Slide 27

Slide 27 text

http://www.ministryoftesting.com/wp-content/uploads/2014/08/graphic_1.jpg.png

Slide 28

Slide 28 text

"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²)

Slide 29

Slide 29 text

● 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

Slide 30

Slide 30 text

Some terminology http://www.natpryce.com/articles/000772.html

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

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

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

● 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

Slide 36

Slide 36 text

http://i.stack.imgur.com/FW1KG.jpg

Slide 37

Slide 37 text

http://fruzenshtein.com/wp-content/uploads/2015/11/place-of-unit-test-in-testing-pyramide.png

Slide 38

Slide 38 text

In a perfect world

Slide 39

Slide 39 text

Dealing with legacy code http://cookdiary.net/wp-content/uploads/images/Spaghetti_15818.jpg

Slide 40

Slide 40 text

● 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

Slide 41

Slide 41 text

● 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

Slide 42

Slide 42 text

● 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!

Slide 43

Slide 43 text

● 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

Slide 44

Slide 44 text

http://10gjera.com/wp-content/uploads/2015/06/bigstock-man-comfortably-sleeping-in-hi-15694625.jpg

Slide 45

Slide 45 text

More resources GOOS - Steve Freeman, Nat Pryce Clean Code - Robert C. Martin Refactoring - Martin Fowler TDD By Example - Kent Beck

Slide 46

Slide 46 text

https://stylestalkerxo.files.wordpress.com/2014/07/1388816856725.png

Slide 47

Slide 47 text

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 [email protected]