[This article was first published on jakub::sobolewski, and kindly contributed to R-bloggers]. (You can report issue about the content on this page here)Want to share your content on R-bloggers? click here if you have a blog, or here if you don't.A specification tells a story.Given describes the world before the action. When describes the action itself. Then describes what changed as a result.If Given is the setup and Then is the payoff, When is where the plot happens, and how you write it determines whether your specifications stay readable for months or decay after the very first change you make to your project.This article is part of a series on Behavior-Driven Development for Shiny applications. We’ve been building a data submission form from scratch, adding an email notification feature, and managing preconditions with Given steps.Read the previous articles to get up to speed, or continue here to focus on how to write When steps.Behavior-Driven Development in R Shiny: A Step-By-Step ExampleBehavior-Driven Development in R Shiny: Setting Up Test Preconditions with Given StepsLevel-up your testing game! Grab your copy of the R testing roadmap.The Purpose of WhenWhen steps answer one question: What is the user doing?Not what button they clicked. Not what input ID was set. What they did, from their perspective.The difference matters because UI implementations change constantly, user behaviors change only when business requirements change. Input IDs get renamed, buttons get moved, forms get refactored into modules. But users still interact with the same form, they submit the same data. If your When steps name those interface details, they break every time something shifts. If they describe user intent, they survive almost any UI change.A When step should read like a sentence from a user story.Compare these two:# Implementation-coupled! Breaks when the submit button is removed or chanedwhen_i_click_submit_button