인수 테스트 설계와 BDD
결국 본질은 하나다
https://www.functionize.com/blog/what-is-gherkin-how-do-you-write-gherkin-testsFeature를 기반으로 각각의 Scenario에 대응하는 Given When Then 구조인 BDD 방법론으로 인수 테스트를 설계하던 중 신선한 충격을 받게 되었다.
테스트 설계 경험의 대부분은 3자 테스팅 조직인 아웃소싱과 게임 개발사에서의 경험이었는데, BDD 방법론을 통한 인수 테스트 설계는, 지나온 경험에서 사용된 테스트 케이스 및 체크리스트의 형태와는 사뭇 다르게 느껴졌기 때문이다.(지금 생각해보면 눈으로 보이는 구조에 차이가 있을 뿐 본질적인 의미는 일맥상통한 게 아닐까 싶다.)
이전부터 CTO님께 BDD의 중요성을 여러 번 들었고, 관련 자료와 프레임워크를 찾아봤지만, 사실상 크게 와닿지는 않았었다. 과거 QA 경험의 관점에선 BDD 방법론으로 쓰인 인수 테스트 설계 방식은, 이전에 내가 해왔던 테스트 설계 방식과 너무나도 다르게 느껴졌기 때문이다. 그러던 중, 3개월간 테스트 자동화에 집중하며 Test Automation Workflow 구축을 하게 되었는데, 이러한 경험이 쌓이고서야 조금이나마 BDD 방법론이 어떤 것인지 와닿게 되었고 중요성을 느끼게 되었다.
BDD 방법론으로 인수 테스트를 설계하던 중에, 정말인지 자동화 스크립트 작성이 편리하겠다는 생각이 들게 되었다. 처음 자동화를 접했을 때 프레임워크를 다루는 방식 중에서 테스트 코드를 작성하려면 describe와 it에 무엇을 테스트할 것인지를 넣으면 된다라고만 학습을 했었다. 그러다 보니, 지금껏 내가 설계한 코드는 유지보수가 어렵거나 어디까지가 무엇을 테스트하는 로직인지에 대해서 명확하지가 않았었다.(Page Obeject Model을 적용했어도)
물론 코드 품질은 신경 쓰지 않고 전체적인 파이프라인 구축에만 집중을 했기에, 코드 품질보단 빠른 구현에 집중함에 따른 문제가 있긴 하지만, 그것과는 별개로 정확히 테스트 범위가 어디까지인지 파악하기가 힘들었다.
그런데 BDD로 인수 테스트를 정리하다 보니 Feature를 기반으로 각각의 Scenario에 대응하는 Given When Then And… 구조가, 이전에 이러한 개념이 없이 자동화 스크립트를 설계할 때 느꼈던 의문인 ‘이 테스트의 정의는 무엇으로 해야 할까?’라는 것들이 조금이나마 해소되었다.
또한 자동화 스크립트를 작성할 때 중요하게 느껴지는 점이 이전과는 사뭇 다르게 다가오게 되었다. 경험이 부족했을 땐 다양한 경우의 수와 많은 테스트를 진행하고자 노력했지만, 현재 아주 약간의 경험이(3개월) 생기고서야 읽기 쉬운 테스트 코드에 대한 이해가 아주 조금이나마 생기기 시작했다.
특히 BDD로 작성된 인수 테스트는 누가 보아도 읽히기 쉽고 이해하기 쉬워야 한다는 관점에서, 과거 expect()에서 비교하는 코드를 작성했던 자신이 약간 부끄러워지기 시작했다. 예를 들면, expect() 안에 특정한 값을 넣고, 그것이 true인지 false인지 비교하려는 코드를 많이 고민했었는데, 지금 생각해보면 이러한 방식이 정말 좋은 테스트 코드를 생산하는 데에 중요할까?라는 생각이 들었다.
지금 생각해보면 해당 코드가 실패할 경우, Error에 Recevied로 받는 값이 false가 될 텐데, 실제로 받는 값을 쉽게 확인할 수 없으므로, 디버깅에도 용이하지 않고, 사람이 보기에도 직관적이지 않기 때문에, 좋은 코드가 아니라는 생각이 들게 되었다. 이러한 생각들을 BDD로 인수 테스트 케이스를 정리하던 중에 배우고 느끼게 되어, 또 한 번 실무에서만 느낄 수 있는 경험치가 존재한다는 걸 배우게 되었다.
기능과 책임을 명시하고, 목적에 대한 상황을 설명하고, 테스트에 필요한 값을 설정하고, 필요한 조건을 명시하며, 보장해야만 하는 결과를 명시하는 구조인 BDD는 결국 로우 레벨의 관점에서 보자면 테스트 대상의 상태 변화를 검증하는 것이었다. 그리고 이는, 3자 테스팅 조직과 여러 QA 사이드에서 활용되는 테스트 케이스와 체크리스트의 본질과도 동일했다. 향후 사용 중인 테스트 자동화 프레임워크에 BDD 툴로 알려진 Cucumber를 연동하여, 보다 좋은 테스트 코드를 만들어보려 한다. 나만이 알 수 있는 코드가 아닌, 모두가 읽을 수 있고 변화하는 비즈니스 로직에 대응 가능한 코드를 말이다.
