Toss SLASH 읽기

유튜브채널 토스의 SLASH 영상을 보고,
저자가 설명한 내용을 다시 설명하는 글입니다.

SLASH 21

테스트 커버리지 100% - 이응준

테스트 커버리지 100%가 되지 않으면 빌드실패하도록 강제하는 시도를 해 본 영상입니다.

• 테스트커버리지 100%는 가능하며, 강제하자.
• 테스트는 빨라야한다. 느리면 프로파일링하여 원인을 해결하자.
• 커버리지가 100%라도 버그는 존재한다.

라는 내용이었습니다.

저자도 100%에 대해 말도안된다는 생각이었지만,
그냥 비판만하지말고 실제로해보기로 입증해보고자 했다는 실증적 정신이 상당히 인상적이었습니다.

이응준 Server Developer님의 발표였는데요.
저도 항상 테스트코드에대한 관심이 매우 크기 때문에 가장먼저 보았습니다.

**동기** : "클린코더" 책에서 100%를 강력히 권고해서.

저자도 `100%? 별론거같은데?` 라고 생각했지만
`실제로 해보기로`했다고하네요.
이 시도가 실패한다고해도 `왜 실패하는지. 왜 어려운지`를 정확하게 알 수 있겠네요

실제로 해본결과? 좋았습니다.

첫째로, main 브랜치에 많은 수정을 올려도 걱정을 덜 수 있다.
정말 큰 장점이겠죠?
둘째로, 항상 자신감있게 리팩토링 할 수 있다.
마찬가지로 테스트의 큰 장점인거같습니다.


겉은 좋아보여도 실행해보면 항상 어려움에 봉착하기 마련인데요.

제가느낀 테스트코드를 짤때 정말 고통스러운 순간은,
- 테스트코드가 리팩터링내성이 없어 리팩터링을 방해할때
- 테스트코드가 너무 느릴 때

이 두가지였던 것 같습니다.
이응준님도 2번째 경우를 크게느끼셨는데요.
테스트케이스가 400개인데도, `1분`가까이 걸렸습니다.
`프로파일링`을 통해 원인들을 찾고 해결법을 적용하여 (+노트북교체) 1600개의 테스트에도 6초까지 줄인 발표가 인상적이었습니다.

#### 99%가 좋을까요? (99% vs 100%)
99%는 `복잡하다`라는 치명적인 문제점을 갖고있어요.

`99개`의 테스팅된 코드가 있다고 해봅시다.
`1개`의 테스트를 갖지않은 코드를 `A`가 추가합니다.
B가 `1개의 테스팅된 코드를 지우면`, 커버리지가 내려가 빌드에 실패합니다.
이에따라 B는 A의코드의 테스트코드를 작성해야하는 상황이 발생합니다.

이는 상당히 어색한 상황이기때문에 100%로 유지하는게 단순명료하고 좋다고 생각되어요