개요
항목 | 내용 |
행사 | Kotlin User Group Seoul 백엔드 밋업 |
주제 | 신입 개발자의 Kotlin, Kotest 입문기 |
발표자 | 임수빈 — 낭만은 잠깐 내려두고 현실을 사는 개발자 |
발표 자료
배경
Kotlin 생태계에 입문한 지 2달 된 신입 개발자로서, Kotlin / Kotest / Exposed / MongoDB 등을 실무에서 처음 접하며 살아남기 위해 익힌 것들을 공유한 발표입니다. 좌충우돌 삽질기를 솔직하게 풀어냈습니다.
사전 지식으로 가정한 것: 람다식 / 함수를 매개변수로 받는 함수, Spring MVC(Controller–Service–Repository) 구조, 단위테스트·통합테스트·테스트 더블 개념
발표 구성
1. Kotlin으로 DTO 만들기
네이버 스토어의 카테고리 DTO를 예시로 Kotlin 문법을 소개했습니다.
•
init 블록 + require를 활용한 유효성 검증 (이름 30자 이하, 단계 1~4 등)
•
함수의 마지막 매개변수가 함수 타입일 경우 람다식을 () 밖에 바로 표현할 수 있다는 Kotlin의 trailing lambda 문법
2. 만든 DTO를 Kotest로 테스트하기
•
JUnit Platform은 JVM에서 테스트가 동작하게 하는 인터페이스, Kotest는 이를 구현한 구현체
•
StringSpec 스타일: String에 operator fun invoke를 정의하여 "테스트 이름" { ... } 문법 구현
◦
operator invoke → 함수 이름 없이 () 만으로 호출 가능
◦
함수 타입이 유일한 매개변수면 () 생략 후 { 람다식 } 으로 호출
•
shouldBe, shouldThrow 등 Kotest Matchers 활용
◦
shouldBe는 infix 함수라서 actual shouldBe expected 형태로 사용 가능
3. Spring과 통합하기
•
@SpringBootTest + Kotest SpringExtension 연동
•
Spring Context 재사용 전략 — 매 테스트마다 컨테이너가 새로 생성되는 것이 아님
•
MockMvc 기반 통합 테스트 작성법
•
Spring Rest Docs DSL 설계: Kotlin의 infix function + extension function을 활용하여 Java 기반의 장황한 Rest Docs 설정을 간결한 DSL로 개선
4. Kotest 최적화
•
테스트 병렬 실행: Runtime.getRuntime().availableProcessors() 기반으로 병렬 스레드 수 설정
•
Spring Context 재사용 확인: 컨테이너가 매번 생성되지 않음을 검증
•
단위 테스트로 전환: 통합 테스트에서 테스트 준비 코드 대비 실제 검증 코드가 극히 적은 문제 → 단위 테스트로 비용 절감
•
MockK 활용: 의존성이 많은 클래스의 테스트 더블을 간결하게 작성
5. Kotest Extension
•
왜 매개변수 없는 공개 생성자가 없다는 에러의 해결법이 의존성 추가인가? 의문에서 출발
•
Kotest Extension 내부 동작 원리 분석
•
Custom Extension 구현: Auto Scan 시 등록 순서 커스텀이 불가능한 문제를 해결하기 위해 Auto Scan을 비활성화하고 직접 등록하는 방식으로 전환
◦
resources/kotest.properties 설정 (IntelliJ Kotest 플러그인 필요)
발표를 통해 공유하고 싶었던 것
•
신입 개발자도 새로운 언어에 빠르게 적응할 수 있다는 경험
•
Kotlin의 언어적 특성(확장 함수, infix 함수, operator 오버로딩 등)을 이해하면 라이브러리의 DSL 설계 방식을 파악하고 직접 만들 수 있다는 점
•
테스트 비용을 낮추는 전략(병렬 실행, Context 재사용, 단위 테스트 전환, MockK)의 실질적 효과
