PyCon 2016 in Portland, Or
hills next to breadcrumb illustration

Sunday 1:20 p.m.–4:40 p.m.

Outside-In TDD

Harry Percival

Audience level:
Intermediate
Category:
Testing

Description

An intermediate-level Test-Driven-Development workshop, presented as a hands-on exploration of "outside-in" TDD, in the style of a code-dojo code kata. Will include discussion of "double-loop" BDD/TDD, outside-in vs inside-out, a detailed discussion of the pros + cons of mocking, test isolation, letting the tests drive design, and what are tests for anyway?

Abstract

So you've decided to start doing testing and you've learned the basics -- how to write a test, how to go through the basic red/green/refactor cycle. Hooray! But now all the intermediate-level questions start to come up: what about different types of test? acceptance tests vs unit tests? How "purist" should I be about isolating my tests? When do I need to mock things, and what's the best way to do that? How do I reach the holy grail of TDD, which is to "listen to my tests" and let them drive the design of my code? Have no fear, answers here! We'll take a concrete example -- adding a new feature to a simple Django web app -- and use rigorous TDD to implement it, exploring our decisions and different testing options and philosophies along the way. We'll see a practical example of "double-loop" TDD featuring different types of tests, and also investigate the idea of "outside-in" TDD, in which the tests drive the development of your application from the UI layer downwards, rather than building bricks from the low-level upwards. We'll discuss when and why that might be a good idea, and how it fits with the MVC pattern. We'll have an extensive, hands-on investigation of the pros and cons of mocking, by writing the same feature once using mocks, and once without -- leading to a discussion of the pros and cons of mocking, and striving for test isolation in your unit tests. In doing so, we'll see if we can get a feeling for "listening to the tests", and the ideal that tests should help drive out good design in our code. All along, we'll be able to discuss why we're writing all these tests anyway, and how to get the best out of them in terms of * Avoiding defects * Writing clean, maintainable code * Achieving a productive workflow (*This tutorial is based on chapters 18 & 19 of my book, [Test-Driven Development with Python](http://www.obeythetestinggoat.com/)*)

Student Handout

No handouts have been provided yet for this tutorial