210804 개발기록: nestjs 테스트코드

 

✅  NestJs, TypeOrm 이게 맞아 ?

nestjs 프레임워크를 사용하여 회사 프로덕트를 개발중이다.

병원 데이터를 다루다 보니, 어떤 쿼리를 날려도 최소 4개 이상의 Table 을 조인하게 된다.

이러다 보니 entity 를 생성하긴 했지만, 제대로 사용하지 못하는 상황에 놓여있다.

즉 TypeOrm 도 사용하지 못한채 QueryBuilder 로 떡칠된 repository layer 를 갖게 됐다.

이러면 NestJs 를 사용하는 이유가 없지 않은가? 라는 의문이 들었지만, 어차피 이런 상황이라면 Spring의 JPA 도 제대로 사용할 수 없다.어떤 프레임워크를 사용하든 도긴개긴이란 뜻이다.

 

 

❌  Test code 의 부재

unit test 를 해보고 싶었다. 여기서도 Entity 를 제대로 사용하지 못한 점이 여실히 드러났다.

querybuilder 를 통해 db에 접근하니 test code 작성이 여간 힘들었다. 

unit test 가 아닌 E2E 테스트를 시도해야했다. 현재 우리 코드의 상황은, entity 를 주입용도로 밖에 사용하지 못하니, 이에 관련된(typeorm) 테스트 코드를 짤 수 없다. 무엇보다 back-end의 현재 기능이 Rest 통신이 우선이다. 그렇기 때문에 더더욱 E2E 테스트에 중점을 두는 것이 맞다. 무엇보다 회사에서 딱히 테스트 코드를 짜라는 말이 없기 때문에,,, 최소한의 공수로 테스트코드를 작성하려면 unit test 보단 e2e 라는 생각이 들었다.

 

이 과정에서 Jest 를 알게 됐다. spring의 mockito 와 느낌이 비슷했는데, mock 객체를 만드는 건 어느 프레임워크나 국룰이구나. 

jest 를 nestjs 에 적용하여 포스팅 해보고 싶다.

 

🌀  힘든 하루였다

부서에 사수나 시니어 개발자가 없다보니 물어볼 상황도 여의치 않다. literally 하루 종일 구글링하며, querybuilder 관련 테스트코드를 찾았는데, 결국 방향이 잘못됐단 결론이 났다. (어딘가 도움을 청하고 싶다 진짜..) 다음주면 신입 개발자 분들이 5명이나 더 들어온다는데, 팀의 최고참은 경력이 10개월도 안된 주니어중에 상 주니어 개발자다.(그게 나다)  

그럼에도, 이 부담감을 정면으로 맞서며 앞으로 나아간다. 지금 힘들다면 잘하고 있는것이라 믿는다.