At the end of the day, our software exists to help users accomplish _some goal_. For end-users, that goal could be to send a picture to a friend, find the least expensive flight, or to calculate annual taxes. When we write software for programmers, we are hoping that our libraries might help them more easily make HTTP requests or parse dates. However, it is easy to lose sight of their goals when we develop software. Sometimes we make breaking changes to our software by modifying features which people were using in unexpected ways. We are familiar with writing unit tests for our code to test granular functionality in our software. This aides in development and helps prevent regressions as we implement new features. We also value this when doing integration testing - testing how the system behaves as a whole. This talk is to talk about Behavior-Driven Development as one tool for creating stronger integration tests. The focus becomes not on testing a "flow" (such as "the customer checkout", or "passing JSON to an HTTP POST request") but on testing what someone is trying to accomplish ("Purchasing tickets for a movie" or "Querying the API to fetch movie information") We will discuss, in detail, how to construct such tests, what makes it difficult, libraries we can use, and specific code examples. We will draw a parallel between translating a human-readable Cucumber feature to code which performs tests and a human-readable RESTful interface and the background code which performs the task at hand. We will also address hype surrounding BDD ("even non-technical people can write tests!") and why it is wrong. We will talk about drawbacks and things which are hard about this approach. We will talk about when and how this can be a useful tool in the integration test toolbox.