From bd0b5fa20861f0df7e73ab86f40c86d502d15ea1 Mon Sep 17 00:00:00 2001
From: NuclearPineapples <41166443+NuclearPineapples@users.noreply.github.com>
Date: Mon, 19 Nov 2018 06:00:12 -0800
Subject: [PATCH] Missing word (#24625)

---
 guide/english/agile/behavior-driven-development/index.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/guide/english/agile/behavior-driven-development/index.md b/guide/english/agile/behavior-driven-development/index.md
index 929ab8ce45..856c578199 100644
--- a/guide/english/agile/behavior-driven-development/index.md
+++ b/guide/english/agile/behavior-driven-development/index.md
@@ -19,7 +19,7 @@ BDD focuses on:
 - How to understand why a test fails
 
 At the heart of BDD is a rethinking of the approach to the unit testing and acceptance testing that naturally arise with these issues. 
-For example, BDD suggests that unit test names be whole sentences starting with a conditional verb ("should" in English for example) and should be written in order of business value. 
+For example, BDD suggests that unit test names should be whole sentences starting with a conditional verb ("should" in English for example) and should be written in order of business value. 
 Acceptance tests should be written using the standard agile framework of a user story: "As a _role_ I want _feature_ so that _benefit_".
 Acceptance criteria should be written in terms of scenarios and implemented as classes: Given _initial context_, when _event occurs_, then _ensure some outcomes_.