김성렬 개발 블로그

프로그램을 작성할 때 습관적으로 유닛테스트 코드를 작성하는 사람과 그렇지 않은 사람 사이엔 그 자체로 이미 프로그래머로서 가능함기 어려울 만큼 깊은 수준차가 존재하는 것이다.

 -임백준(BaekJoon online 운영자)-

유닛 테스트는 정말 중요하다.  군대에서 토비 스프링을 통해 스프링을 처음으로 접했고

이일민 개발자님의 책을 읽으면서 유닛테스트의 목적을 배우고

테스트 코드는 단순히 잘 돌아가나? 를 보기위한 대충작성하는 것이 아니라는 것을 배웠다.

단위테스트를 하는 이유는 개발자가 설계하고 만든 코드가 원래 의도한 대로 동작하는지를 개발자 스스로 빨리 확인받기 위해서다.

이때 확인의 대상과 조건이 간단하고 명확할수록 좋다.

-토비 스프링 vol1-

 창업당시 서비스 오픈을 최대한 빠르게 해야 했다.

최소한의 창업 준비 또는 진행 성과가 좋아야 학교에서 청년 창업을 위해 지원하는 투자금을 타낼수 있었기 때문이다.

클라우드서버 구입과 관리 서버내 리눅스로 환경구성하는 것 대한 문제도 전부 나의 업무였다.

AWS를 쓰려다가 클라우드서버 사용경험이 전무했기때문에

"그래도 한국 업체이면 전화문의로 한국말로 도움을 받을수 있지 않겠느냐 "라는 의견들이 나와서 KT UCloud  를 이용하기로 했었다. 

(지금생각하면 후회한다. 상업화되지 않은 테스트 단계에서 AWS 프리티어로도 충분했는데 큰돈은 아니지만 쌩돈을 썼다.)

처음 하는 일은 늘 그렇듯 힘들었다.

(내가 최고권한서버관리자인데 왜 permission deined 냐

권한좀 주세요 ㅠㅠ 리눅스님 ..

-09월21일 카톡 일기-)

 그러나 어플서버 개발또한 병행 되어야 했고

서버쪽은 개발이 가능한 사람은 나뿐이였기 때문에 많이 지쳐갔다.

그렇기에 나는 매우 합리적인? 결정을 내렸다.

유닛테스트코드를 생략했다. 그때 당시  CRUD 관련 유닛테스트 코드들은 잘 작성 되있었고. Service 계층을 짜는 단계라서

"db에서 잘받아 오는데 뭔 문제 있겠어

문제가 있으면  로그 찍어서 어찌어찌 해결 되겠지"라는 생각을했다

처음에는 문제가 없었다.

그러나 문제는 어플과 연결시킨 한참뒤에 벌어졌다.

입력값이 몇 개가 비었을때, 특수 문자 입력을 막아지 않을것, 과 같이 클라이언트(어플)단의 굉장히 사소한 문제들이 

Service 단에서 예외 처리를 미숙하게 해놓은점 ,선언적 트랜잭션 처리를 생각없이 전부 선언 한것 과 같은 나의 미숙함이 곂치면서 심심하면 어플이 꺼지는 문제가 생겨났다.

문제는 어디서 발생한 에러인지 정확히 몰랐기 때문에 하나의 버그가 발생하면

하나의 기능에 관여하는 클라이언트와 서버 의 모든 클래스를 까봐야 했다.

에러로그로 간단하게 잡히는 문제들도 있었지만

문제는 같은 에러를 잡아 놓고도 다음주가 되면 새로운 에러를 잡기위해 완벽하다 생각했던

소스코드를 다시 검토 해봐야 했다.

기능 추가로 새로운 도메인?이 필요하여 DB에 테이블을 추가하고 그에 필요한  클래스들에는 지금있는 버그들 때문에 바쁘다는 핑계로 테스트코드를 작성하지 않았다.

이런 악순환은 계속되었다.

그때 조금만 더 고생하더라도 테스트 코드를 작성해놨으면 

같은 소스코드를 반복해서검토하고

그때그때 이거 돌아가나? 라는 생각에 main열어서 임시로 돌려보고 다시 지운다던지

하나의 클래스를 테스트하기 위해 어플 부터 서버db 끝까지 전부 한번 돌려봐야만

기능 테스트가 가능한 이런 끔찍한 문제가 안일어 났을까란 생각이 든다.

그때 내가 자주 했던 부끄러운말이 있다

"오늘 서버 테스트 해봐야될거있으니까 다들 모여주세요"

나는 책을 통해 수많은 문제들을 보았고 그 문제들을 해결하는 솔루션을 책을 통해 배웠지만

실제 상황에서 대처하지 못했다.

Junit을 쓸줄알고 mokito를 사용해 더 깔끔한 테스트 코드를 만들어 내는 것과 같은 일들을

아는것과 하는것은 전혀 다른 문제 같다.

개인적인 생각이지만

개발과 설계,관리는 분리되는게 맞는것같다. 두개를 동시에 하기는 힘든 것 같다.