𝟯 𝗧𝗵𝗶𝗻𝗴𝘀 𝗡𝗼𝗯𝗼𝗱𝘆 𝗧𝗲𝗹𝗹𝘀 𝗬𝗼𝘂 𝗔𝗯𝗼𝘂𝘁 𝗕𝗗𝗗

Your Cucumber suite takes forty minutes to run. You cannot explain what a single feature file tests without reading layers of code.

Many teams adopt BDD because business stakeholders need to read tests. Then, those stakeholders stop reading. You end up with a maintenance nightmare.

Here are three truths about BDD.

𝟭. 𝗚𝗵𝗲𝗿𝗸𝗶𝗻 𝗶𝘀 𝗻𝗼𝘁 𝗮 𝗽𝗿𝗼𝗴𝗿𝗮𝗺𝗺𝗶𝗻𝗴 𝗹𝗮𝗻𝗴𝘂𝗮𝗴𝗲

Stop writing test scripts in Gherkin. If your scenarios list every click and every field, you are doing it wrong.

Bad Gherkin:

  • Given the user enters email "test@example.com"
  • And the user enters password "Password123!"
  • And the user clicks "Place Order"

Good Gherkin:

  • Given the user has items ready to purchase
  • When the user pays with a valid credit card
  • Then the order is confirmed

The "how" lives in your step definitions. The "what" lives in your feature files. Keep your feature files simple so a product manager can read them in seconds.

𝟮. 𝗦𝘁𝗲𝗽 𝗱𝗲𝗳𝗶𝗻𝗶𝘁𝗶𝗼𝗻𝘀 𝗮𝗿𝗲 𝗻𝗼𝘁 𝗮 𝗱𝗲𝗽𝗲𝗻𝗱𝗲𝗻𝗰𝘆 𝗴𝗿𝗮𝗽𝗵

Do not make step definitions import other step definitions. This creates a tangled web. If one step fails, it poisons the entire state.

The fix is simple:

  • Separate your page objects from your step definitions.
  • Use a shared domain layer.
  • Step definitions should be thin wrappers that call domain objects.

This makes your steps stateless. You can change one part of your code without breaking every other scenario.

𝟯. 𝗕𝗗𝗗 𝗶𝘀 𝗮 𝗱𝗼𝗰𝘂𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻 𝗽𝗿𝗼𝗷𝗲𝗰𝘁

BDD is about communication, not just testing. The tests are a side effect.

If you optimize only for test coverage or execution speed, you lose the main goal. Your feature files should be the first thing a new engineer reads to understand your system.

If a person cannot understand your system by reading your feature files, your BDD suite has failed.

𝗪𝗵𝗮𝘁 𝘁𝗼 𝗱𝗼 𝘁𝗼𝗺𝗼𝗿𝗿𝗼𝘄:

  • Pick your worst feature file.
  • Rewrite scenarios to be three to five lines long.
  • Move data into step definitions or factories.
  • Replace step-to-step imports with domain objects.

Can you explain your system to a new hire using only your feature files in five minutes? If not, start rewriting.

Cucumber 테스트 스위트가 유지보수 지옥이 되기 전, 아무도 말해주지 않는 BDD에 관한 3가지 사실

BDD(Behavior-Driven Development, 행위 주도 개발)는 꿈처럼 들립니다. 비즈니스 이해관계자, 개발자, 그리고 테스터가 모두 동일한 언어를 사용하는 세상을 약속하죠. 스프린트 리뷰 중에 "제 말은 그게 아니었는데요"라고 말할 일도, 버그 분류 중에 "요구사항이 불분명했습니다"라고 변명할 일도 없게 될 것 같습니다.

하지만 곧 현실이 닥칩니다.

처음에는 몇 개의 깔끔하고 아름다운 feature 파일로 시작합니다. 그러다 서서히 feature 파일의 수가 늘어납니다. Gherkin 단계(step)는 점점 더 복잡해집니다. 어느 순간, 새로운 기능을 작성하는 시간보다 깨진 step definition을 수정하는 데 더 많은 시간을 쓰고 있는 자신을 발견하게 됩니다. 한때 신뢰의 원천이었던 Cucumber 테스트 스위트는 이제 유지보수 지옥이 되어버렸습니다.

이 지점에 도달하기 전, 아무도 말해주지 않는 BDD에 관한 세 가지 사실이 있습니다.

1. BDD는 테스트 도구가 아니라 커뮤니케이션 도구입니다

가장 큰 실수는 BDD를 테스트를 작성하는 방법이라고 생각하는 것입니다. BDD는 테스트 도구가 아닙니다.

BDD의 일차적인 목표는 'Three Amigos'(기획자, 개발자, 테스터) 간의 커뮤니케이션을 촉진하는 것입니다. Gherkin 문법은 그 커뮤니케이션의 부산물일 뿐입니다.

만약 BDD를 단순히 자동화 테스트를 작성하기 위해서만 사용한다면, 핵심을 놓치고 있는 것입니다. 결국 유지보수가 어렵고 실제 비즈니스 가치를 반영하지 못하는 거대한 테스트 스위트만 남게 될 것입니다.

진정한 마법은 단 한 줄의 코드도 작성하기 전에 일어납니다. Three Amigos가 함께 앉아 Gherkin을 사용하여 요구사항을 명확히 하고, 예외 케이스(edge cases)를 찾아내며, 무엇이 "완료(done)"인지에 대해 공통된 이해에 도달할 때 마법이 일어납니다.

핵심 요약: 테스트를 위해서가 아니라, 대화를 위해 BDD를 사용하세요.

2. Gherkin의 함정: 명령형(Imperative) vs 선언형(Declarative)

이 지점이 대부분의 Cucumber 테스트 스위트가 무너지는 곳입니다.

Gherkin을 작성할 때, 사용자가 무엇을 달성하려고 하는지(what)보다는 사용자가 어떻게 동작하는지(how)를 설명하려는 경향이 있습니다. 이를 '명령형(Imperative)' 작성 방식이라고 합니다.

명령형 (나쁜 예):

Given I am on the login page
And I enter "user@example.com" in the email field
And I enter "password123" in the password field
And I click the "Login" button
Then I should see the dashboard

이 방식은 매우 취약합니다. 만약 UI가 변경되어 이메일 필드가 사용자 이름(username) 필드로 바뀌거나, 버튼 텍스트가 "Sign In"으로 변경된다면 테스트는 깨집니다. 이는 동작(behavior)이 아니라 구현(implementation)을 테스트하고 있는 것입니다.

선언형 (좋은 예):

Given I am a logged-in user
When I navigate to the dashboard
Then I should see my account overview

선언형 Gherkin은 *의도(intent)*에 집중합니다. UI 변경에 훨씬 더 유연하며, 비즈니스 이해관계자들이 읽기에도 훨씬 쉽습니다.

핵심 요약: 어떻게(how) 일어나는지가 아니라, 무엇이(what) 일어나는지에 대해 작성하세요.

3. Step Definition의 폭발적 증가

테스트 스위트가 커짐에 따라 한 가지 패턴을 발견하게 될 것입니다. 새로운 Gherkin step이 생길 때마다 코드에 새로운 step definition이 필요하다는 사실입니다.

주의하지 않으면, 수백 개, 혹은 수천 개의 작고 매우 구체적인 step definition이 생겨나게 됩니다. 이것이 바로 "Step Definition의 폭발적 증가"입니다.

Given I click the "Submit" button Given I click the "Cancel" button Given I click the "Save" button

이들은 모두 본질적으로 동일한 동작이지만, 세 개의 서로 다른 step definition을 필요로 합니다. 이는 코드베이스를 비대하게 만들고 탐색을 매우 어렵게 만듭니다.

이를 방지하려면 step definition을 재사용 가능하고 일반적(generic)으로 설계해야 합니다. step 텍스트에 값을 직접 하드코딩하는 대신 매개변수(parameter)를 사용하세요.

나쁜 예: Given I click the "Submit" button

좋은 예: Given I click the "{string}" button

이렇게 하면