코딩 스킬만큼 중요한 BDD 컨셉 2가지
Background & Scenario Outlines
안녕하세요, 클래스팅에서 Selenium Appium E2E 테스트 자동화 리드를 담당 중인 지오입니다. 코드 방식 자동화는 복잡합니다. BDD(Cucumber)와 이번 포스팅에서 언급하는 2가지 개념을 실무에 활용하지 않는다면요. 오늘 주제인 코딩 스킬만큼 중요한 BDD 컨셉 중 Background & Scenario Outlines에 대해 알아보겠습니다.
BDD(Behaviour-Driven Development)란?
BDD와 그렇지 않은 방식에 대한 javascript, python 경험담이 담긴 과거 포스팅을 참고하시면 좋습니다.
Background 필요한 이유
예를 들어, 이메일 로그인 피처에 유효/비유효 시나리오 검증 필요한 상황입니다. 시나리오를 위와 같이 구성했습니다. 단계(Step) 파일의 테스트 코드에 문제가 없다면 실행에 문제가 없습니다. 그런데 불필요한 중복 단계를 거치고 있습니다. 이를 Background 키워드로 제거할 수 있습니다.
Feature 하위에 Background 키워드를 작성하여 각 시나리오의 공통 단계를 작성했습니다. 이로써 중복 단계였던 Given과 When의 가독성 및 유지보수가 원활해졌습니다.
Scenario Outlines 필요한 이유
앞서 Background 키워드로 중복 단계를 쉽게 제거하는 방법을 보여드렸는데요. Background 키워드만으로는 해결되지 않는 문제가 남아있습니다. 예를 들어, 이메일 로그인 시나리오의 유효/비유효 입력값에 대한 검증이 필요한 상황에서 Scenario Outlines를 사용하지 않는다면 어떻게 될까요?
예시로 위와 같이 구성할 수 있습니다. 다만 유효/비유효 검증에 대한 경우의 수는 블랙박스 테스트 설계 기법을 통해 보다 신뢰성 높은 커버리지로 설계되어야 하고, 설계된 커버리지는 가능한 자동화 필요합니다.
그런데 위 시나리오의 문제점은 무엇일까요? 얼핏 보기엔 문제가 없습니다. 다만 유효/비유효의 조합은, 경우의 수를 계산한다면 이보다 더욱 많습니다.(이와 비슷한 개념으로 페어와이즈 기법을 떠올리시면 좋습니다.)
실제 고객은 개발팀이 의도한 방향으로 제품을 사용한다는 보장이 없기에 요구사항 분석 및 설계 관점에서 공인된 테스트 설계 기법을 활용하여 테스트 케이스 고도화가 필요합니다. SW QA 분야의 테스트 지식을 깊게 학습하다 보면 Happy Path(행복 경로) 개념이 등장하는데, Happy Path 뿐 아니라 예외 케이스라 불리는 네거티브 테스팅 관점에서도 블랙박스 테스트가 진행되어야 합니다.
본론으로 들어가, 위 시나리오의 문제점은 Background와 동일한 관점에서 중복이 많다는 점입니다. 만약 유효/비유효 커버리지의 조합이 수십수백 개가 된다고 가정한다면, Scenario Outlines을 사용하지 않을 경우 모든 경우의 수를 코드로 작성해야 합니다. 그렇다면 Scenario Outlines을 사용해서 해당 문제를 어떻게 해결할 수 있는지 살펴보겠습니다.
데이터를 넘겨줘야 하는 경우 위와 같이 Scenario Outline의 Example을 사용해서 테스트 필요한 데이터 개수만큼 넘겨줄 수 있습니다. 이것이 가능한 이유는 Given 조건에 해당하는 코드가 모두 동일하고, 유효/비유효에 대한 테스트 데이터 및 대응하는 기대 결과만 달라지기 때문입니다.
참고로 Cucumber에서 테스트 데이터가 필요할 경우 하드코딩 없이 Cucumber 표현식을 활용하면 좋습니다. 관련 공식 문서는 아래입니다.
https://github.com/cucumber/cucumber-expressions#readme
GitHub - cucumber/cucumber-expressions: Human friendly alternative to Regular Expressions
지금까지 코딩 스킬만큼 중요한 BDD 컨셉 2가지, Background & Scenario Outlines에 대해 알아보았습니다. SW QA 사이드에서 진행하는 Selenium Appium 기반의 E2E 테스트 자동화는, 객체지향 디자인 패턴과 같은 코딩 스킬뿐 아니라 중복을 피하기 위해 설계된 프레임워크를 잘 활용하는 것도 중요합니다.
많은 기능을 자동화시킬수록 유지보수 난이도가 급격히 높아지는 E2E 테스트 자동화, 디자인 패턴에 대한 학습도 중요하지만, Cucumber와 같은 BDD 프레임워크를 활용하여 보다 효율적인 테스트 자동화를 시도해보는 것도 좋은 방향이라 생각합니다.
감사합니다.
