Toss SLASH 감상

2024-06-27

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

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

라는 내용이었습니다.

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

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

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

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

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

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

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

제가느낀 테스트코드를 짤때 정말 고통스러운 순간은,

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

99%는 복잡하다라는 치명적인 문제점을 갖고있어요.

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

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