테스트 특강 내용에서 주어담았던 내용들을 다 짬뽕시켜서 이 글에 다 넣었습니다. 이번 특강 너무 재밌었어요~
테스트 코드를 왜 작성하는 걸까?
여기서 말하는 테스트는 수동 테스트를 제외한 프로그램과 코드를 이용한 자동 테스트들을 말한다.
1. 사람이 직접 모든 경우의 수를 테스트 하는 것은 한계가 있기 때문이다.
2. 테스트 코드를 작성해야 코드에 대한 확신을 가지고 리팩토링을 진행 할 수 있다
3. 테스트 코드가 명세서가 된다
테스트 코드가 필요했던 상황들 예시
실제로 있었던 일을 각색했습니다.
시나리오1: 깃훅 라이브러리 제작
- git 자동화 라이브러리(byul - npm)를 만들고 있다고 가정해보자. 이를 수동으로 테스트한다면?
- 코드가 바뀌거나 기능을 추가 할 때마다 테스트를 하기 위해서 새로운 폴더에 git을 설치하고 npm 설치하고, 일일히 모든 설정들을 해줘야 한다.
- 그리고 깃을 사용할 때 여러 시나리오(git commit, git merge, git 관련 툴을 사용하는 경우, git messge가 너무 긴 경우)를 모두 테스트해야 한다.
- 그리고 막상 쓰다 보면 npm i나 npm i -D, 또는 npm이 아닌 pnpm, bun을 사용하는 경우 그리고 window와 리눅스 환경에 파일 시스템 고려안하고 개발해서 어디선가 버그가 나온다.
- 테스트 코드를 작성했더라면 많은 git을 사용할 때의 수많은 시나리오를 고려해서 테스트도 가능하고, 매번 테스트 환경으로 수동으로 만들어야되는 고생이 덜 했을 것이다.
시나리오2: 생일 케이크 애니메이션
- 웹사이트에 생일 케이크를 svg와 css 애니메이션으로 만들고, 직접 크롬 브라우저 띄워서 잘 나오고 있는 것을 내 두 눈으로 똑똑히 확인했다.
- 그런데 막상 배포하고 safari 모바일 브라우저를 보니 케이크는 어디가고 빈화면만 나왔다. (배포하고 크롬에서만 잘 나온다.)
- 이래서 배포 하기 전에 사파리 브라우저에 대한 테스트는 꼭 해야한다.
시나리오3: 코드 리팩토링
- 로그인 기능을 만들고 코드가 더러워서 리팩토링을 했는데, 리팩토링 이후 로그인이 안된다.
- url 이동 로직이 더러워서 리팩토링을 했는데, 리팩토링 이후 홈 화면으로 이동이 안된다.
- 내가 만들었던 기능들이 리팩토링하고나니 다 없어졌다. 내가 아닌 다른분이 리팩토링을 진행했는데 해당 기능이 꼭 필요한 기능인지 몰랐다고 한다.
- 테스트 코드에 해당 기능들에 대한 명세가 되어 있거나, 리팩토링을 진행하면서 테스트를 같이 했다면 이런 일이 덜 했을 것이다.
그 외에 테스트를 해야 하는 많은 이유
너는 이미 테스트를 하고 있다.
간단하게 react앱을 실행하고 브라우저 화면을 확인하거나, 포스트맨으로 API 테스트 정도는 할 것 이다.
많은 테스트케이르를 테스트 할 수는 없겠지만 수동 테스트도 충분히 한다면 일단은 문제는 없을 것이다.
리팩토링은 테스트 없이는 불가능
테스트를 진행을 하고 나서 리팩토링을 진행한다면 각 코드의 기능에 대해 알 수 있고, 리팩토링 이후에도 코드의 해당 기능이 제대로 작동하고 있는지 알 수 있다.
각 함수에 대해 인풋 아웃풋이 정확히 무엇인지 잘 작동하는지 확신을 가지게 되서 훨씬 리팩토링이 수월할 것이다.
그리고 보다싶이 위의 시나리오3을 보면 리팩토링 이후에 이전의 기능들을 보장하지 않는 경우가 있다.
리팩토링의 정의는 기능에 대한 변화 없이 코드 품질을 올리는 행위이다. (나는 리팩토링을 한게 아니다)
리팩토링 자바스크립트 라는 책에서는 아예 '테스트 없이 리팩토링을 진행하는 것은 리팩토링이 아니다'라고 말하고 있다.
마틴 파울러의 코드 기능 추가와 리팩토링 2가지 개발 모드
마틴 파울러는 코드 기능 추가와 리팩토링 2가지 모드로 개발을 진행해야 된다고 한다.
코드 기능 추가 는 코드가 이전과 동작이 달라지게 하고 새로운 기능을 추가하는 행위이고, 리팩토링 은 기존 동작을 보장하면서 설계 수준을 올려서 소프트웨어의 품질을 올리는 행위라고 한다.
엄격히 구분해야 되며 코드 기능 추가 중에는 리팩토링을 해서는 안되고 리팩토링 중에는 기능 추가를 해서는 안된다.
그런데 여기서 유의해야 될 점이 버그를 고치는 것도 마찬가지로 기능 추가 행위에 포함이된다.
이 말의 핵심은 반드시 리팩토링 진행 하기 전에 버그를 먼저 고쳐야 된다라는 소리다.
반드시 기능 추가와 리팩토링은 구분 되어야한다.
[마틴 파울러] 리팩토링의 중요성 feat.테스트 코드를 짜는 이유(한글 자막) - YouTube
대규모 업데이트(종속성들 업데이트)를 할 때 테스트가 큰 도움이 된다.
종속성들의 버전을 올린다음에도 기능들을 모두 업데이트 한다음 해당 코드가 여전히 잘 작동되는지 확인을 해야한다.
가능하면 모든 코드 실행 흐름과 시나리오를 테스트 해야 될 것이다. 왜냐하면 이전 종속성들이 버전과 동작이 크게 달리지는 경우가 많으니까
eslint가 대표적이다. eslint를 v9버전으로 안올리는 사람이 너무 많다.
테스트를 통한 빠른 버그 발견
테스트를 작성하면 초기 단계(코드 작성 단계)에사 버그 진압이 가능해진다.
배포되서야 버그를 확인하게 되는 것은 너무 끔찍하다.
그럼 어떤 테스트를 할 것인가?
일단 대표적인 테스트 방식은 E2E 테스트(종단테스트) 와 유닛 테스트(단위 테스트)가 있다.
- E2E 테스트(종단 테스트):
- 어플리케이션의 각 기능들에 대한 테스트이다.
- 유저 관점에서 테스트에 가깝다.
- 실제로 유저 시나리오 기반으로 E2E 테스트를 진행하기도 한다.
- 전체적인 어플리케이션의 시스템을 테스트 한다고 해서 시스템 테스트라고도 한다. - 유닛 테스트(단위 테스트):
- 어플리케이션의 각 기능들을 이루고 있는 함수들, 객체, 메서드들을 인풋 아웃풋 등 세부사항들을 테스트 하는 것이다.
- 유저 보다는 개발자 관점에 테스트에 가깝다.
어떻게 테스트를 할 것인가? (테스트 코드 주의 사항)
테스트 방법은 다음 글에서 적을 것이고 여기서는 테스트를 할 때 주의사항을 적고 마치도록 하겠다.
1. 테스트 코드를 짤 때구현 세부사항에 집중하지 않는다.
함수를 테스트 한다면 함수에 내부 동작에 대한 테스트가 아니라 인풋들(매개변수 참조 변수, this, 등)과 아웃풋(리턴값, 사이드이펙트)를 테스트 해야 된다는 뜻이다.
왜냐하면 세부 구현 사항들은 언제든지 달라질 수 있고, 리팩토링을 통해 더 나은 품질의 세부사항들이 항상 바뀐다.
2. mock을 이용해서 테스트를 격리시키기 격리되어야 한다.
react 코드를 작성한다면 특정 외부 서버 API에 의존하는 동작들도 있고, 백엔드라면 특정 상황이나 DB에 의존하는 코드들이 있다.
이런 코드들을 임의의 가짜 데이터와 가짜 서버, mock을 만들어서 테스트를 해야된다. 그렇지 않으면 테스트의 성공/실패 유무가 외부 서버나 외부 데이터에 달려 있게 된다.
우리는 그런 외부 API 테스트나 DB테스트가 아니라 우리의 함수와 react 컴포넌트를 테스트할 것이다.
3. 기능 구현과 코드 품질 사이 균형 맞추기
-
마감이 다가오면 테스트를 일일히 다 작성하기 어려울 때도 많다. 그렇다고테스트 코드가 중요하다고 중요한 기능들 만드는 것을 내팽겨처리는 것은 맞지 않다.
-
이럴 때는 수동 테스트라도 꼼꼼하게 해야한다.
-
PR에 내가 만든 기능을 최대한 자세히 설명해서 코드가 내가 의도하지 않은 방향으로 수정되버리는 것을 막아야한다.
-
그리고 PR을 올리기 전에 다른분들 코드를 merge를 하고 프로그램을 실행시켜서 수동으로 꼼꼼히 다 테스트를 해야한다.
-
테스트를 진행하는 것은 미래의 나를 위해서이다. 나중에 코드를 까보면 이게 뭐였는지 알 수없고. 코드도 유지보수가 필요해보이는데 코드를 조금만 고쳐도 고장나버린다. 이럴 때 과거에 나한테 '아 테스트 코드를 짜둘 걸...' 하고 후회를 하게 될 수도 있다.(그러게요. 테스트 코드를 짜둘걸 내가 왜그랬을까요.)
특강 후기
- 개인적으로 이번 특강은 직접 테스트코드도 짜볼 수 있어서 좋았다.
- 무려 배민 개발자분이라서 물어볼게 많았는데 질문을 많이 못한 것이 한이다.
