목적

가장 큰 목표는 사내에 테스트 코드를 짜는 문화를 도입하는 것이었습니다.

회사에 처음 입사했을 때 기존 서비스를 다른 프레임워크로 컨버팅 하는 업무를 맡게 되었습니다. Nuxt.js 를 Next.js 로 변경하는 작업이었는데, 어려운 로직은 없었지만 프레임 워크를 변경했을 때 해당 기능이 여전히 동작하는지 확인하는 부분이 까다로웠습니다. 히스토리 파악이 잘 되지 않는 부분들에 있어서는 제대로 변경을 한 것이 맞는지 확신을 할 수 없었고, 또한 모든 페이지의 기능을 일일이 실행해보기에는 리소스가 많이 들었습니다.

또 다른 프로젝트에서 Vue2 2.6 이하 버전에서 Vue2.7 (composition api 지원)를 사용한 코드로 변경했을 때, webpack 에서 vite 로 번들러를 변경했을 때도 마찬가지로 변경한 코드가 이전과 동일하게 동작하는지 확인해야 했습니다. 다 테스트를 했다고 생각했지만 프로젝트 전체를 확인하기란 불가능에 가까웠고 결국 오류가 발견되어 배포 이후에 hotfix 로 고쳐야 하는 상황이 발생했었습니다.

현재 Vue 코드를 React 로 변경하는 작업을 하고 있습니다. 아무리 꼼꼼하게 테스트를 하고 개발한다고 해도 오류가 발생할 가능성이 분명히 존재합니다. 과거와 유사한 상황이 반복되지는 않을까 불안해하기보다는 이 문제를 해결하는 것이 좋겠다고 생각했습니다.

삼진 규칙(rule of three)

최근에 리팩토링 2판을 읽고 있는데, 리팩토링 책에서 소개하는 삼진 규칙(rule of three) 이 인상적이었습니다.

삼진규칙 : 스트라이크 세 개면 Refactoring을 한다.

• 어떤 것을 처음 할 때는, 그냥 한다.
• 두번 째로 비슷 어떤 것을 하게 되면, 그냥 중복되도록 한다.
• 세 번째로 비슷한 것을 하게 되면, 그때 Refactoring을 한다.

저의 경우는 코드를 리팩토링해야 하는 것은 아니지만 개발 프로세스를 리팩토링하는 것이므로, 개선을 요하는 상황이 세 번 이나 반복된 지금이 리팩토링 해야 할 시기라고 생각했습니다. 회사의 개발 문화도 변화시키면 앞으로 컨버팅하거나 개발하는 데에도 오류를 줄일 수 있고 개발 속도 향상에 기여할 수 있을 것이라는 판단 하에 사내에서 테스트 코드 스터디를 만들게 되었습니다.

방법

이전까지 테스트 코드를 짜본 적이 전혀 없었기 때문에 방법을 고민하던 중 글또에서 몇 주 전에 추천글이 올라온 이펙티브 소프트웨어 테스팅 도서를 기반으로 스터디를 진행하게 되었습니다. 다양한 테스트를 다루지만 그 중에서도 ‘단위 테스트’를 위주로 다루는 도서라서 제가 테스트를 도입하고자 하는 상황에 적절하다고 느꼈습니다. 라이브러리를 바꿔도 input 에 따른 output 이 동일함을 보장한다면 안심하고 코드를 변경할 수 있을텐데 UI 보다는 로직에 집중한 단위테스트를 학습하고자 했습니다.

다만, 해당 도서는 java 로 예제 코드가 이루어져 있어서 typescript 로 변경하는 작업이 필요했습니다. 진행한 스터디의 방식은 다음과 같습니다.

1. java → typescript 로 예제 코드 변경
2. 변경된 예제 코드를 기반으로 도서를 읽으면서 테스트 코드 작성
3. PR 을 통해 다른 스터디원들이 작성한 테스트 코드가 잘 작성되었는지 확인 & 피드백
4. 학습하면서 느낀 추가적인 insight 공유

목표는 1회당 1장씩 매주 2회씩 스터디를 진행하는 것이었습니다.

지금까지 진행한 것

지금까지 총 2장을 진행했습니다. https://github.com/effective-software-testing/code 레포지토리에 나와 있는 java 예제 코드를 typescript 로 바꾸고, 책을 읽으면서 학습을 하고 있습니다.

1장 요약

효율적인 테스트

• 기능 구현 시에는 코너 케이스를 크게 고려하지 않고 생각나면 일단은 다른 곳에 기록해놓는다.
• 코드 작성 이후에 테스트에 집중한다.
• 너무 적으면 버그가 많이 발생할 수 있고, 많으면 비효율적이 된다.
• 프로그램을 완벽히 테스트하는 것은 불가능하다 ⇒ 효율적으로 테스트해야 한다.

제대로 된 설계에 대한 미신

• 코드가 단순한 것 ≠ no bug
• 단순한 코드와 좋은 설계도 모든 버그를 막지 못한다. → 결국 테스트가 필요하다.

테스트 비용

• 상용 버전에서 발생하는 버그 > 예방 비용(테스트 코드 작성) 일 때 테스트를 작성하자.
• 연습을 통해 테스트 작성을 빠르게 하도록 하자
• 결함 클러스터링
  • 버그가 특정 구성요소에 많이 분포되어 있다.
  • 해당 부분 위주로 테스트를 작성하자.
  • ex) 결제 모듈

2장 요약

테스트를 도출하는 방법 7단계

1. 요구사항 이해
   • 요구사항에 대한 전반적 이해
   • 수행해야 하는 것/하지 말아야 하는 것
   • 코너 케이스
   • 입출력 변수 타입과 범위
2. 프로그램 탐색
   • 프로그램을 직접 실행시켜보기
3. 구획 식별
   • 입력값의 범위 살피기
   • 각 변수 간의 상호작용을 살펴보기 + 의존성
   • 출력값의 범위 살피기, 테스트 범위 정하기
4. 경계 분석
   • 경계 분석해서 목록에 추가
5. 테스트 케이스 고안
   • 예외 케이스는 한 번만 테스트
6. 테스트 자동화
   • vitest 와 같은 툴 이용하기
   • 테스트 중복 줄이기
   • 실패 시 알아보기 편하도록 하기
7. 강화(창의성과 경험)
   • 최종 점검
   • 테스트 고도화

실용적인 명세 테스트

• 단위에서의 가능한 한 조합의 수를 줄인다.
  • 도메인 지식을 활용해서 적용되지 않는 케이스 제거하라
  • 다른 동작과 동떨어진 엣지 케이스를 테스트를 중심으로 테스트하자
• 메서드 수준에서 많은 조합이 발생하면 메서드를 분리하는 것이 좋을 수 있다.

합리적인 테스트

• 테스트 범위가 아닌 것에 대해서는 현실적인 값을 사용하자. (자주 사용하는 값, 계산이 쉬운 값)

어려웠던 점

java 코드 변경의 번거로움

java 예제 코드를 typescript 로 변경하는 작업이 생각했던 것보다 꽤 오래 걸렸습니다. 로직 중심으로 java 코드를 대략적으로는 이해할 수 있지만, 테스트 코드를 짜려면 코너 케이스나 경계값들을 알아야 했습니다. java로 되어 있는 코드가 정확하게 어떻게 돌아갈 지 100% 파악하기 어려웠기 때문에 java 문법을 검색해야 하는 추가 작업이 필요했습니다. 테스트를 공부하고자 한 것인데 부가적인 일들이 늘어나면서 코드 짜는 것에 집중을 덜하게 되었습니다.

스터디장의 부재

제가 해당 스터디를 만들기는 했지만, 테스트를 잘 아는 상태에서 스터디를 이끄는 것이 아니라 함께 학습하기 위해 만들었기 때문에 테스트에 대한 지식이 거의 없었습니다. 물론 같이 스터디를 진행하시는 분들도 처음 테스트코드를 짜는 것이다보니 ‘이게 맞나?’ 라는 생각으로 스터디가 진행되었습니다.

아직 10% 정도 밖에 진도가 나가지 않아서 일단은 학습을 조금 더 하면서 생각을 해보자고 일단락 내게 되었습니다.

느낀점, 개선 방향

부담(욕심) 내려놓기

단지 흥미 목적이 아니라 업무에 가까워지면서 각 스터디원들이 부담감을 느끼게 되었습니다. 특히 처음에 제가 의욕이 넘쳐서 1주에 2회의 스터디를 제안했었는데 생각보다 책이 잘 안 읽히고 테스트 코드를 짜는 데에도 시간이 많이 들게 되면서 저를 포함한 스터디원들이 버거워했습니다.

결국 업무에 지장이 가지 않도록 스터디의 강도를 낮추게 되었습니다. 사내 스터디의 경우 특히나 업무와 연관이 있을 수 있어서 일과 분리가 되지 않을 수 있으므로 강도를 처음부터 높이는 것이 좋지 않다는 것을 깨닫게 되었습니다.

철저한 준비

다음에 사내 스터디를 만들 때는 준비를 철저히 해서 만들거나 스터디 준비 위원회(?) 등을 만들어서 다른 분들의 도움을 받아 체계적으로 정리한 후에 스터디를 운영하려고 합니다.

스터디 시작과 동시에 진도를 따라가느라 바빠서 스터디 진행 방법을 개선하는 것이 쉽지 않았습니다. 또한, 제가 책을 전체를 다 읽어서 어느 부분이 중요한 지 모르는데 스터디를 이끌려고 하니 어떤 방법도 확신이 생기지 않아서 결정이 늦어지고 혼란스러운 부분이 생겼습니다.

다음에 스터디를 만들게 되면 제가 모르는 것이 100% 인 분야가 아니라, 제가 70%는 알고 30% 정도 추가적으로 공부하고 싶을 때 만들어야겠습니다. 혹은 스터디를 위해 먼저 공부하는 시간을 갖고 제안을 드리는 것이 스터디를 참여해주신 분들의 시간을 덜어드리는 일이 될 것 같습니다.

구체적인 목표 정하기

사내 스터디는 문제를 해결하고자 하는 명확한 목표가 있어야 합니다. 회사에서 함께 업무하는 사람들과 하는 공부라서 ‘업무’ 라는 부담을 지우기는 어려울 것 같습니다. 그렇다면 이를 상쇄할 만큼의 성취감을 얻을 수 있도록 모두가 공감하는 문제가 있어야 합니다.

제가 컨버팅하면서 테스트가 있으면 좋겠다고 느끼기는 했지만, 그것이 어떤 범위인지 테스트를 당장 어떤 프로젝트에 적용할 지 명확하지 않은 채로 스터디를 시작했습니다. 그러다보니 각자 해당 내용을 어디에 적용해야 할 지 의문이 들어서 스터디의 효용성에 의문을 갖게 되었습니다. 성능을 개선하든, 리팩토링을 하든, 새로운 프로젝트에 도입을 하든 구체적으로 학습하는 내용을 적용해볼 수 있도록 탐색을 통해 적절한 범위를 정한 이후에 스터디를 하면 더욱 효과가 좋을 것 같습니다.

다음주까지 지금까지 배운 테스트 관련 지식을 어디에 적용하면 좋을 지 찾아보고 공유하기로 했습니다.