[잡담] 아...단위테스트 정말로 싫다
글쓴이: emptynote / 작성시간: 화, 2020/06/02 - 8:54오전
우선 용어 정리 부터 하겠습니다.
'비동기 메시지 보내기' 기능이란 입력 메시지에 대한 처리 결과 메시지를 기다려 받지 않고
입력 메시지를 보내는 기능을 말합니다.
'비동기 메시지 보내기' 기능 구현시 난관에 봉착했는데요.
대기 없이 입력 메시지를 보내기때문에 처리 용량에 한계를 갖는 서버가 견디지 못하네요.
이것에 대한 해결책으로 속도 조절을 찾았고 이에 수정하여 단위테스트 해야 하는데
아...socket write 가 걸려 있어 이것을 mock 할려니 현타오네요.
내 코드가 얼마나 못났는가를 알 수 있는 검증을 생략하고 싶어요 ㅠ.ㅠ
Forums:
통신테스트가 멘붕오는 경우 많죠. 고생하이소
통신테스트가 멘붕오는 경우 많죠. 고생하이소
파이팅 외쳐봅니다
막연히 단위테스트 도입하면 좋을거라고 생각했는데
막연히 단위테스트 도입하면 좋을거라고 생각했는데
이 문구를 보고나니, 조심해야겠다는 생각이 듭니다.
단위 테스트 특성상 유닉스 철학을 따를 수 밖에 없습니다.
단위 테스트 특성상
"각 프로그램이 하나의 일을 잘 할 수 있게 만들 것." 라는 유닉스 철학을 따를 수 밖에 없습니다.
그런데 동작하게 하는것을 우선으로 개발을 하는 것이 인지 상정이라 이 원칙이 쉽게 무너집니다.
내 눈의 티는 내가 알 수 없지요.
남이 봐 주거나 거울을 봐야 알 수 있지요.
단위테스트가 바로 거울 역활을 합니다.
단위 테스트가 화이트 박스 테스트이다 보니 2개 이상의 기능이 합쳐 있다면
검증 난이도가 상승하여 검증하는데 애를 먹게 됩니다.
msg 조금 쳐서 예를 들자면
1개 기능에 n 개 테스트가 있고 다른 1개 기능에 m 개 테스트가 있다면
분리를 하면 n + m 이지만
합쳐저 있는 경우 n * m 경우로 테스트 해야 합니다.
하여 자연스럽게 단위 테스트를 하다 보면
함수 혹은 메소드가 1개 기능만 갖는 '테스트 하기 쉬운 코드' 로 흘러가게 됩니다.
왜냐면 단위 테스트할때 고생 안하고 싶거든요.
저는 단위테스트 힘들고 어렵지만 추천 드립니다.
마지막으로 다시 한번 강조하지만 '테스트 하기 쉬운 코드' 가 만능은 아니다는 사실을 말하며
이만 글을 마치겠습니다.