오늘은 어제 코드를 건드린 post 패키지의 테스트 코드를 작성했습니다.
저는 지금까지 테스트 코드를 한 번도 짜본적이 없어서
단위 테스트를 하면서 Latency도 같이 측정하는 것이라고 생각했었습니다.
하지만 좀 찾아보니
테스트는 단위 테스트, 통합 테스트, 인수 테스트 그리고 성능(부하) 테스트가 있더군요.
보통 테스트 코드를 작성한다고 하면 단위 테스트를 작성한다고 많이들 하는 거 같습니다.
테스트 코드를 작성함에 있어 어떤 걸 검증해야 하고, 어디까지 검증해야 할까?
이것이 오늘의 제일 큰 고민이 되었던 것 같습니다.
열심히 서치도 해보고, 주변 지인에게 물어본 결과,
단위 테스트의 경우 컨트롤러보다는 서비스와 리포지토리 메서드를.
그리고 단순한 CRUD 로직보다는 복잡한 로직에 대해서 단위 테스트가 필요함을 인지할 수 있었습니다.
Ex. 조건이 들어가는 비즈니스 로직, Query 어노테이션을 통한 조회
(물론 이것도 제가 나름 정한 저만의 기준이고, 정답은 아닌거 같습니다.)
통합 테스트의 경우 일단은 모든 API를 하는 것으로 정했습니다.
복잡한 로직의 경우 당연히 모듈간의 결합성을 고려해 진행해야 한다고 생각했고,
단순한 CRUD의 경우 단위 테스트를 배제한만큼 통합 테스트라도 진행해야 한다고 생각했습니다.
환경 구성에 있어서도 고민이 되었는데
단위 테스트는 단순히 로직의 구현이 올바르게 되었는지를 체크하므로 H2 인메모리 데이터베이스를 통해
빠른 테스트를 하는 게 낫겠다는 생각이 들었습니다.
통합 테스트의 경우 실제 환경과 유사해야 하므로 테스트 컨테이너를 @Testcontainers 어노테이션을 통해 MySQL을 띄우는 식으로 진행했습니다.
팀원에게 liquibase를 추후에 써보면 어떻겠냐는 의견을 제안 받았는데,
이제 테스트 컨테이너는 단순히 DB를 띄운것이고 테이블을 생성해주는 DB 형상관리 툴인것 같습니다.
저희 프로젝트는 현재 JPA를 사용중이므로 ddl-auto 설정을 통해 테이블을 생성할 수 있어
일단은 배제해도 괜찮다는 판단을 내렸습니다.
아래 링크는 어제 오늘 작성한 코드가 담긴 PR입니다.
https://github.com/TechForkTeam/TechFork-server/pull/121
내일 할 일
1. 테스트 전용 yml 파일 생성
하지만 현재 테스트 코드에 통합 테스트를 위한 yml 파일이 따로 없습니다.
이게 어떻게 동작하나 봤는데, 기본값인 local-tunnel.yml로 동작하더군요.
이 파일은 ddl-auto가 update이고, 운영 환경과 연동되는 yml 파일이므로,
테스트를 위한 별도의 yml 파일을 생성하는 것을 내일 해볼 예정입니다.
이 파일은 테스트에 걸맞게 ddl-auto가 create-drop으로 설정하여 진행할 예정입니다.
2. Post 엔티티와 TechBlog 엔티티 정규화 진행

원래는 이런 구조로 DB를 구성하려고 했는데
크롤링하면서 회사 이름을 가져오다보니 posts에도 company라는 회사이름을 나타내는 필드가 존재하게 되었습니다.
이 구조는 같은 정보를 중복해서 저장하므로 정규화에 위배됩니다.
이를 TechBlog 엔티티의 companyName을 사용하도록 통일시키는 정규화를 내일 진행해볼 예정입니다.
'프로젝트 > Techfork' 카테고리의 다른 글
| [26/01/01] 오늘의 개발 일지 - OCI 서버 배포 완료 (0) | 2026.01.01 |
|---|---|
| [25/12/31] 오늘의 개발 일지 - Oracle Cloud Infrastructure 가입! (0) | 2026.01.01 |
| [25/12/30] 오늘의 개발 일지 - 테스트 컨테이너 스프링 빈으로 변경 (0) | 2025.12.31 |
| [25/12/27] 오늘의 개발 일지 - 테스트 환경 구성 (0) | 2025.12.30 |
| [25/12/25] 오늘의 개발일지 - 조회수 필드와 저장 방식에 대한 고민 (0) | 2025.12.26 |