개인 프로젝트를 하면서 TDD를 하고 있다. 간단하지만 풀스택 프로젝트여서 '백엔드를 만들 때 적용했던 TDD를 프론트엔드에도 적용해 보자!'하는 단순한 생각으로 시도했다. 동료 분과 Nest에서 작성했던 jest 코드를 바탕으로 하면 되겠지'하는 생각으로 덤벼들었지만, 프론트엔드는 프론트엔드 만의 특징들이 있었고 이런저런 레퍼런스 그리고 컨퍼런스 영상들을 찾아보고서 BDD(Behavior Driven Development)를 기준으로 작성하기로 했다. 주로 Describe-Content-It 템플릿으로 작성을 했고 중점은 사용자가 화면에서 어떤 행동을 할 지에 맞춰서 테스트 코드를 작성하자는 것이었다. 이 글은 이런 규칙 속에서 약 10개월 간 BDD를 하기 위해 무작정 맨 땅에 헤딩을 한 중간 기록을 남겨보고자 한다. 방법론적인 글이 아니라, 하면서 느낀 점을 기록하는 글이기 때문에 예시 코드는 거의 없을 거 같다.

최근 하고 있는 BDD 개발 사이클

기록을 남겨야 겠다고 생각했던 결정적인 이유는 최근 들어서는 꽤 이런 개발 방법도 가치가 있다는 것을 느끼고 있기 때문이다. 처음에는 그냥 화면에 나오는 하나하나의 요소들을 가지고 테스트를 작성했다. 예를 들어 라벨과 인풋 태그가 있다면 라벨과 인풋 태그의 '존재'를 검증하는 테스트 코드를 작성해 보았다. 하지만 가면 갈수록 이런 테스트가 무슨 의미가 있을까에 대한 회의가 들었다. 그에 대한 고민을 하다 보니, 유저가 실질적으로 컴포넌트와 상호작용하는 부분을 중심으로 테스트 코드를 작성해 보기 시작했다.

이런 고민 끝에 최근에 내가 개발하는 사이클은 다음과 같다. 실제 사례를 들어보면, 최근 input태그에 입력하고 엔터를 누르면 카테고리 태그가 추가되는 등의 태그와 관련된 UI를 만들었다. 이때 테스트 코드를 작성할 때 대략적으로 사용자가 이 UI에서 어떤 상호작용을 할지 고민을 해보았다.

1. 태그 input에 유저가 새로운 태그를 입력
2. 태그를 입력하고 enter를 눌러 태그 추가
3. 태그를 클릭하여 태그 삭제
4. 예외 사항을 고민해 보니, 이미 존재하는 태그와 동일한 값의 태그는 추가되지 않아야 하고,
5. 빈 input 값이면 태그는 추가되지 않아야 한다.

위 다섯 가지는 실제로 테스트 코드를 작성하기 전에 간략하게 적어본 수도 코드이다. 이 값은 절대적이지는 않고 작성 과정에서 몇 가지 사항들이 수정, 추가될 수 있다. 그리고 이에 따라 테스트 코드를 하나 작성한다. input에 유저의 입력을 테스트 한다. getByRole로 input태그를 테스트 환경 스크린에서 가지고 와서 userEvent나 fireEvent를 사용하여 input에 값이 잘 입력되는지 확인한다. 하지만 이 테스트는 반드시 실패한다. 왜냐하면 input 태그를 아직 만들어 두지 않았기 때문이다. 그럼 input 태그를 만들고 리액트 환경이기 때문에 input을 위한 상태와 설정자 함수를 설정한다. 이렇게 하면 1번 상황은 테스트가 통과될 것이다. 이후 코드를 실행시켜 UI에서 실제로 내가 예상한 동작이 잘 되는지 확인한다. 2번도 똑같이 테스트 코드를 작성하고, 실패하고, UI를 그에 맞게 작성하고, 테스트가 통과되면 실제 UI를 확인한다. 이 방법으로 5번까지 코드를 쭉 작성했다.

내가 느낀 효용

이렇게 개발을 했을 때 글로만 봤던 몇 가지 효용을 느낄 수 있었다. 가장 먼저 몰입도가 올라갔다. 예전에 글에서 TDD를 하면 능률이 오른다는 말을 보고 이해를 잘 못했다. 그런데 실제로 몰입도가 올라가면서 능률이 올랐는데, 포인트는 이것이다. BDD를 하다 보니 상기한 내용처럼 정형화된 개발 순서가 생겼고, 그에 따라 개발 과정이 매우 직관적이어진다. 이전에는 UI를 개발했다가 유저와 상호작용하는 핸들러를 만들고, CSS작업 좀 하다가 핸들러에 예외 처리하다가 안되면 다시 돌아가서 만져보고 뭔가 코드가 지저분 한 것 같다, 아니면 재사용하기 어려워진 것 같다 할 땐 UI와 로직을 분리하는 등 그냥 머리에 떠오르는 대로 작업을 한 것 같다. 이것도 나름의 장점이 있었을 태지만, 개인적으로 정형화된 개발 순서에 따라 하나씩 해결해 간다는 느낌이 훨씬 몰입이 되었다.

다음으로는 하나의 문서가 작성되는 것이다. 하나의 describe 블록은 해당 스크린이고 Context는 상황을 나눈다. 그리고 it은 각 상황에서 유저가 겪을 수 있는 다양한 상호작용을 나타낸다. 즉, 해당 컴포넌트 안에서 유저가 마주칠 수 있는 여러 상황에 따라 테스트 코드를 작성하다 보니 하나의 문서가 완성된다. 내가 빠뜨린 예외 사항은 어떤 것이 있고, 이 부분은 조금 더 보완해야 한다는 것이 한 눈에 들어온다. 심지어는 동료 분이 작성한 코드가 이해가 안 될 때는 테스트 코드를 먼저 읽기도 했다. 읽다 보면 어떤 상황에 유저에게 어떤 행동을 기대하는 코드인지, 유저에게 어떤 것을 제공하기 위한 코드인지 파악하기 쉬워졌다.

또 유저 입장에서 어떤 상황을 겪을지를 생각하다 보니, 코드를 작성할 때 유저 관점에서 많은 생각을 하게 되었다. '최초 UI를 설계할 때는 몰랐지만, 특정 부분은 유저 입장에서는 헷갈릴 것 같다', '이 부분은 유저 입장에서는 있으나 마나 한 버튼인 것 같은데 왜 존재할까?'와 같이 UI대로 그저 화면에 그리는 것이 아니라 이 UI에서 유저가 어떤 상호작용을 할지 계속 생각하게 되면서, 더 목적이 분명한 코드를 작성할 수 있었다.

이런 매력에 빠져서 최근에 BDD를 통해 더 몰입도가 높은, 그리고 하나하나의 사이클을 달성할 때 마다 오는 즐거움과 성취감을 느끼며 개발을 하고 있다. 이런 즐거움을 느낀지는 오래 되지 않았지만 분명 새로운 경험이었고, 이 글을 적게 된 가장 큰 이유이다.

여기까지 오면서 겪은 불편함, 어려움

뭐든지 말은 쉽다. 하지만 여기에 더 많은 중간 과정들이 추가된다. 반복되는 테스트 코드들은 beforeAll이나 beforeEach에 함수로 묶어주어 테스트 코드를 좀 더 쾌적하게 만들고, 생각대로 UI가 작동하지 않는 부분은 다시금 수정하는 과정을 거친다. 그리고 모킹을 해야 하는 부분은 모킹을 하지 않게 설계를 수정할 수 있는지, 설계를 수정하는 것이 실제 코드에서 불합리함을 유발한다면 모킹을 어느 정도까지 해야 하는지, 외부 패키지를 사용한다면 그 부분은 어떻게 처리를 할 것인지, 어떻게 테스트를 해야 하는지 모르는 부분은 React Testing Library Documents들을 보면서 이런 저런 시도를 하는데 많은 시간을 써야 한다. 즉, 나는 빠르게 UI를 구현하고 싶은데 BDD를 하면 그렇게 할 수 없다. 단순히 기능을 완성하는 것도 테스트 코드 3,4줄은 추가적으로 만들기 마련이다. 이런 부분 때문에, 재미를 느끼기 전까지는 테스트 코드를 작성하면서 '배보다 배꼽'인 것 같은 생각이 훨씬 더 자주 들었다. 그러면서 회의감에 사로 잡힐 때도 있고, 굳이 테스트를 작성해야 하는지에 대한 의문도 자주 생겨, 회의에서 자주 테스트에 대한 고충을 토로하기도 했다.
특히나 익숙해 지면 이런 부분이 덜하지만 처음에는 아주 간단한 테스트 코드 하나를 작성하는데도 상당한 시간과 노력이 든다. 하나부터 열까지 찾아보면서 '이 단순한 테스트가 도대체 왜 테스트가 통과가 되지 않는 것이지?', '각각의 메소드의 차이는 뭐지?'하는 막막함에, 재미를 느끼기 전에 훨씬 먼저 TDD의 단점을 온 몸으로 느끼게 될 것이다. 나 또한 그랬다.

모두에게 권하고 싶지는 않다.

그래서 각자의 상황과 처지에 맞게 시도해 보라고 권하고 싶다. 나야 개인 프로젝트이고, 동료 개발자와 함께 서로 해보고 싶은 것을 마음 껏 해보는 프로젝트라서 아무것도 모르는데 시도해 본 것이다. 하지만 한 번도 테스트를 해보지 않은 분들이라면 실패와 삽질을 너그러이 받아들일 충분한 마음의 여유가 있는 분들에게 권하고 싶다. 앞서 말했듯이 경험이 없기 때문에 별 것도 아닌 것 같은 부분에서 어마어마한 삽질을 하는 경우도 허다하다. 그렇다고 겁 먹을 필요는 없다. 나도 호기심에 이끌려서 그냥 했다. 그래서 그냥 여러 번 부딪히고 찾아보고, 동료 분과 이야기를 나누며 큰 틀에서의 컨벤션을 정하고, 그 안에서 일정한 시행착오를 겪고 나서야 어느 정도의 효용을 느꼈다. 유데미와 같은 강의를 이용한다면 이런 시행착오의 시간을 훨씬 줄일 수 있을 것이지만, 이것 역시 개인의 취향일 테니 잘 고민해 보길 바란다.