[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.You’ve set up all the preconditions.You’ve triggered the action.Now the specification needs to answer one question: did the system do the right thing?That’s what Then steps are for. How precisely you answer it determines whether your specifications act as a reliable safety net or produce false confidence.This article is the 3rd part of a series on writing BDD specifications for Shiny applications. We’ve built a data submission form, managed preconditions with Given steps, and modeled user interactions with When steps.Read the previous articles to get full context, or continue here to focus on writing Then steps.Behavior-Driven Development in R Shiny: A Step-By-Step ExampleBehavior-Driven Development in R Shiny: Setting Up Test Preconditions with Given StepsBehavior-Driven Development in R Shiny: Writing When Steps That Model User BehaviorLevel-up your testing game! Grab your copy of the R testing roadmap.The Purpose of ThenThen steps answer one question: What changed as a result of the user’s action?Not how it changed internally. What the user can now observe — or what the system has now done — that wasn’t true before.This distinction shapes every Then step you write. The assertion lives at the level of the outcome, not at the level of the mechanism that produced it.# Outcome — what the user cares aboutthen_there_are_entries