테스트 코드에 대한 결정

outline

 테스트 코드에 대한 최근 결정을 작성한다.

 

contents

https://nebulayoon.tistory.com/25 해당 링크에서 디자인 패턴에 대한 생각을 작성했다.

작성했던 글을 읽다보니, 왜이리 변명만 작성했지? 내가 작성하려던건 이런게 아닌데 라는 생각이 들었다.

그래서, 이어서 현재 나의 생각과 결정 사항을 작성해보려고 한다.

 

우선은 이 글의 목적에 맞게 테스크 코드에 대해서 작성해볼까 한다.

https://nebulayoon.tistory.com/25 해당 글에서 repository pattern을 사용해서, in-memory repository를 구현하는 것은 비효율적이라고 했다.

 

이 당시에, 왜 그렇게 생각했는가?

raw query를 사용하는 service는 수많은 조회를 이용해야한다. 대시보드 형태라 접속을 하는 순간 chart 등의 정보를 제공하기 위해서 수많은 백엔드 호출이 동시에 일어나며, 평균적으로 raw query는 cte 8개, 라인 300줄, raw query는 최소 5개이상의 테이블을 join하고, 연산하고(avg, vector 등), DB에는 extension들이 설치 되었다.

 

즉, 유저 수가 적고, 빠른 속도 조회를 위해서 raw query에 비즈니스 로직을 적용했었다. 코드 레벨에서는 테스팅을 할 수 없다. 반드시 integration testing을 해서, raw query를 검증해야만 했다.

 

다행히(?), 해당 로직들은 한번 잘 만들고 나면, 수정될 가능성이 거의 없었다. 전세계적으로 공용으로 사용하는 수치를 계산하는 일이였기 때문에, 직접 수치를 보면서 하나 하나 테스팅을 했다.

 

하지만, 시간이 지나면서, api수도 많아지니까 직접 관리하기 힘들어지면서, integration testing 코드를 작성했다.

 

또 다른 서비스는 데이터를 입력하는 위주의 CRUD app이다.

해당 서비스는 기존 서비스 처럼 raw query를 써야할 정도로 조회 속도를 요구하는 것도 아니며, 비즈니스 로직이 복잡하지도 않았고, 소스 코드 레벨에서 처리해도 충분한 처리량이 나왔다.

 

다만, 이 서비스는 insert를 하기 위한 조건이 까다로운 편이였는데, 말 그대로 transaction 신경을 쓰면서도, insert하기 위해서 소스 코드 레벨에서 확인하는 비즈니스 로직이 많았다.

그래서, 이 서비스에는 unit test를 최대한 도입하여, 작업하기로 결정했다.

 

위와 같이 결정을 한 이유는,

회사에 제안하여 스프린트를 도입하게 되었는데, 나의 제안으로 인해서 QA시간을 하루 넣기로 하였다. 무조건 e2e테스트로 사람이 직접 눌러보면서 문제가 있는 걸 찾기로 했다.

QA시간으로 인해서, 사전에 문제점을 찾아서 fix 후에 배포한다는 프로세스가 생겼고, 이로 인해서 큰 문제점들이 많이 줄었다.

하지만, 기능은 반드시 늘어나는데, 언제까지나 QA시간동안 사람이 모든 케이스에 대해서 처리하는 것은 힘들어질 것이다. 현재, QA 테스트 때 마다, 새로운 기능 뿐만 아니라 모든 기능을 항상 확인하는데, 이 부분의 심리적, 물리적 부담을 줄이고 싶었다.

 

end

무엇이 중요한지, 언제 해야하는지, 가치가 있는 일인지 판단하는 능력이 많이 향상된 것 같다.

회사는 결국 돈을 벌거나, 비용을 줄이거나, 이 2가지 논리에 의해서 작용 한다는 것을 이해하고, 상황에 따라서 판단하는 능력이 길러진 것 같아서 좋다.

다만, 아직 나의 지식의 부족함에서 오는 비효율성을 처리하지는 못한다. 아무리 따로 공부를 한다지만, 회사에서 작업하면, bad case, good case를 발견하기 마련이다.