Test-Driven Development is not a way to test—it's a way to code. A way that helps you write clear code that stays clear. And clearer code is cheaper to change.

But TDD doesn't come naturally. It's almost impossible to adopt before the right architectural boundaries are in place. Boundaries that your code probably doesn't have yet.

In this session, I'll show you how to draw the hard lines in your code that keep your software soft. I'll test-drive changes in a real app—no boring toy examples here. I'll be coding live (mistakes and all), so you can see what it’s really like to work this way. And we'll cover important concepts like:

+ Declarative vs. Imperative UI code
+ Mocking dependencies (like API calls and storage)
+ Unit-testing asynchronous code

Boundaries, people! Let's make TDD make sense, and make our changes cheaper.