We know testing is vital and makes refactoring painless. But how to set sail to that TDD treasure? Yarr, we need to test to get experience, but need experience to test. Let’s draw a map with simple strategies for identifying test cases and building a robust test suite. X marks the spot w/ TDD tools for newbies and seasoned pirates alike.

== The Details
It’s easy to find the benefits of testing and test-driven development. There’s a reason why the ruby community is gaga over red to green, robust, well-rounded, and high code coverage test suites. This session assumes that the audience does not need convincing to want to test. The "sweet spot" audience is those who still have trouble deciding what to test before they write a line of application code.

They'll leave with a technique built on BDD that will allow them to make real, concrete decisions on what in their current work should/could have a test written. Going from business rules, product definition and requirements to pseudocode to tests is straightforward with this technique, and each step informs the next, bridging that gap between blank file and test suite.

Outline -

# TDD is good
* prevent regressions
* helps prevent complexity by setting small tasks & goals
* safer refactoring
* increasing returns with the lifetime of the project
* living documentation

# TDD is Hard
* how do we know what to test when we haven't written the code?

# Introduce the TDD Treasure Map technique
## The Map
* entry points
* where does this section of code begin?
* branches
* what questions exist that change the flow of the code?
* if statements, side effects, polymorphism etc
* end points
* where does this section of code under test end?
* what are the states that lead to there?
* translate entry points to test setup
* translate end points to expectations
* given, when, then

## Simplified example
* use real world language and situations to draw the map & tests
* simple example
- one ruby class or method, no dependencies
- identify this as a unit test
- draw the map and follow through with tests
* complex example
- one class or method that depends on another
- draw the map and highlight where dependencies come into play
- talk about how a mock or stub would play into keeping the tests simple
* zoom out
- show how this technique can apply at all the layers of the testing pyramid
- use example of user-flow to demonstrate at a product-size level

== The Pitch
The talk centers around a technique I’ve refined while mentoring new programmers. They’ve just learned how to write code, and now all of a sudden it sounds like they’re being asked to visualize all the code they’ll have in the future and devise tests for it before they start.

It involves drawing something like a map, hence the piratical theme, of the controller, the feature, the class, or the method you’re testing. Visualize (or draw out, or pseudocode!) this map from all the starting points you can think of, to all the end points you can think of.

Likely you’ve stumbled across a few things you hadn’t thought of before, and made the future code better in the process, hey this imaginary future feature doesn’t seem so far away! But wait.. still have to write tests first. How else do you know when you’re successful?

Taking the flowchart again, look at every endpoint. Every different way the code can resolve. Trace it back to the starting point, through however many decisions and turns it took to get there. What did you start with to reach that endpoint? That’s the start of your test. That’s your “given”. That path you traced is your “when”. That endpoint? You guessed it, the “then.”

Not only have you built a mental model of the feature you’re setting out to build, but you’ve devised your test cases. Now go write them! All of a sudden you have a map, you’ve got that friendly guide along feature development that is your test suite.

I’ve hashed over this talk idea with co-workers and colleagues, and many have taken it to heart and started using it in their work. Whether they’re beginners or experienced programmers, this is a tool I’ve found can work in many different situations, and help get those first high-level feature tests up and running.

I’ve been in tech for a handful of years now, but I’ve been a speaker for over a decade. I’ve taken the stage at corporate conferences and trade shows, as well as theatres and circus rings. I try to bring a lightness and excitement to my talks to share the excitement I feel about the topics I cover.

First Public Delivery: RailsConf 2022 (Portland USA)
Preferred Session Length: 30 Minutes