kotlin-testing

kotlin-testing 스킬 개요

kotlin-testing은 어떤 용도인가

kotlin-testing 스킬은 Kotlin 프로젝트에서 테스트를 작성하고 개선하는 방법을 실용적으로 정리한 가이드입니다. 핵심은 팀이 실제로 가장 자주 필요로 하는 작업, 즉 Kotest 스타일 선택, MockK로 의존성 모킹, 코루틴 테스트를 올바르게 수행하기, 그리고 테스트 코드를 보일러플레이트로 만들지 않으면서 property-based test와 Kover 커버리지를 활용하는 데 있습니다.

누가 설치하면 좋은가

Kotlin 앱에 테스트를 추가하거나, 팀의 테스트 방식을 표준화하거나, Kotlin다운 TDD 워크플로를 원한다면 kotlin-testing 스킬을 설치하세요. 특히 JVM Kotlin 프로젝트에서 작업하면서, 즉흥적인 테스트 프롬프트보다 반복해서 쓸 수 있는 패턴이 필요한 개발자에게 가장 유용합니다.

어디에 가장 잘 맞는가

이 스킬은 종단 간(end-to-end) 프레임워크 설정이 아니라, 신뢰할 수 있는 unit/component 커버리지가 목표인 테스트 자동화 작업에 잘 맞습니다. 첫 테스트를 작성해야 하거나, 깨지기 쉬운 assertion을 리팩터링해야 하거나, Kotlin에 맞는 방식으로 mocks와 coroutines를 분리해 테스트하는 방법을 이해해야 할 때 도움이 됩니다.

kotlin-testing 스킬 사용법

작업 공간에 kotlin-testing 설치하기

먼저 저장소의 설치 흐름에 따라 스킬을 설치한 뒤, 테스트 코드를 요청하기 전에 에이전트를 skills/kotlin-testing 컨텍스트로 지정하세요. 저장소에 안내된 기본 설치 명령은 다음과 같습니다:
npx skills add affaan-m/everything-claude-code --skill kotlin-testing

가장 좋은 결과를 내려면 Kotlin 코드가 실제로 있는 같은 작업 공간에 설치하세요. 그래야 실제 파일, 패키지 이름, 빌드 도구를 기준으로 스킬을 활용할 수 있습니다.

테스트할 Kotlin 대상은 구체적으로 지정하기

kotlin-testing 스킬은 한 번에 하나의 구체적인 대상과 하나의 원하는 테스트 결과를 명시할 때 가장 잘 작동합니다. 예를 들면 클래스나 함수 이름, 이미 쓰고 있는 프레임워크, coroutine 동작이나 mocking 규칙, coverage 기준 같은 제약을 함께 적어 주세요.

프롬프트 예시:
Use kotlin-testing to write Kotest tests for UserService.createUser. Mock the repository with MockK, cover success and duplicate-email failure paths, and keep the tests compatible with our Gradle/Kover setup.

먼저 읽어야 할 파일부터 확인하기

SKILL.md부터 시작한 뒤, README.md, AGENTS.md, metadata.json, 그리고 존재한다면 rules/, resources/, references/, scripts/ 폴더를 확인하세요. 이 저장소에서는 SKILL.md가 가장 중요한 기준 문서이므로, 프롬프트를 작성하기 전에 “When to Use,” “How It Works,” “Examples” 섹션을 먼저 읽는 것이 가장 빠른 방법입니다.

스니펫만 보지 말고 워크플로를 따르기

이 저장소는 테스트 우선 흐름을 중심으로 구성되어 있습니다. 즉, 대상을 식별하고, Kotest spec을 작성하고, 의존성을 mock 처리한 다음, 실패하는 테스트를 실행하고, 코드를 구현한 뒤, ./gradlew koverHtmlReport로 커버리지를 확인하는 방식입니다. 그래서 단순한 예시 assertion보다 실행 계획이 필요할 때 이 스킬의 가치가 더 큽니다.

kotlin-testing 스킬 FAQ

kotlin-testing은 TDD에만 쓰는가

아닙니다. TDD가 이 스킬의 기본 워크플로이긴 하지만, 이미 존재하는 Kotlin 코드에 테스트를 덧붙일 때도 유용합니다. 구현 코드를 이미 갖고 있다면, 이 스킬을 사용해 집중된 coverage와 더 깔끔한 mocks를 추가하세요.

일반 프롬프트를 대체하는가

Kotlin에 특화된 판단이 필요할 때는 일반 프롬프트보다 확실히 낫습니다. 예를 들어 어떤 Kotest 스타일을 쓸지, coroutine을 어떻게 mock할지, coverage를 어떻게 생각할지 같은 부분입니다. 일반 프롬프트도 테스트는 작성할 수 있지만, kotlin-testing은 프레임워크 적합성과 테스트 구조에 대한 시행착오를 줄여 줍니다.

초보자도 쓰기 쉬운가

네, 테스트할 Kotlin unit이나 class 하나를 설명하고 가이드된 테스트 계획을 원한다면 충분히 쓰기 쉽습니다. 다만 빌드 시스템을 모르거나, 아직 테스트 대상이 없거나, 구체적인 테스트 코드보다 넓은 수준의 아키텍처 조언이 필요한 경우에는 덜 유용합니다.

언제 kotlin-testing을 쓰지 말아야 하는가

브라우저 자동화, API contract testing, 또는 Kotlin 이외의 테스트 스택을 대신하는 용도로는 쓰지 마세요. 문제의 핵심이 인프라, 불안정한 integration 환경, test data 관리라면 kotlin-testing보다 더 넓은 범위의 test automation 스킬이 더 적합합니다.

kotlin-testing 스킬 개선 방법

“테스트를 작성해 줘”보다 더 구체적인 맥락을 주기

가장 좋은 kotlin-testing 결과는 정교한 입력에서 나옵니다. 즉, 테스트 대상 클래스, public methods, 중요한 분기, 그리고 맞추고 싶은 기존 테스트 스타일을 함께 알려 주세요. Kotest의 StringSpec, FunSpec, BehaviorSpec 중 무엇을 원하는지도 적는 것이 좋습니다. 읽기성과 구조가 그 선택에 따라 달라지기 때문입니다.

까다로운 제약은 처음부터 분명히 말하기

코드가 suspending functions, flows, private collaborators, 엄격한 coverage gate를 사용한다면 생성 전에 먼저 알려 주세요. 예를 들어: Use MockK for the repository, test this suspend function with coroutine test support, and keep the assertions compatible with Kover coverage goals.

실패 경로까지 커버리지를 요청하기

이 스킬은 “하나의 성공 테스트”보다, happy path와 failure path를 함께 요청할 때 가치가 가장 큽니다. 함수가 null을 반환할 수 있거나, 예외를 던지거나, 재시도하거나, 입력을 검증한다면 그 케이스를 명시해서 생성된 suite가 실제 판단에 바로 쓸 수 있게 만드세요.

테스트 설계를 좁히면서 반복 개선하기

첫 결과를 받은 뒤에는 빠진 내용을 기준으로 프롬프트를 더 구체화하세요. 예를 들면 edge case, 네이밍 규칙, fixture 설정, 불안정한 의존성 같은 부분입니다. kotlin-testing을 가장 빠르게 개선하는 방법은 생성된 spec을 검토한 뒤 overmock되었는지, undercovered되었는지 확인하고, 아직 필요한 정확한 branch를 지정해 더 좁은 범위로 다시 요청하는 것입니다.