안녕하세요 저는 공통시스템개발팀에서 플랫폼 개발을 담당하고 있는 김규남이라고 합니다. 이 글은 올해 사내에서 진행한 코틀린 밋업에서 스프링에서 코틀린 스타일 테스트 코드 작성하기라는 주제로 발표한 내용을 바탕으로 작성한 글입니다. 코틀린에서 테스트를 작성하기 위한 여러 도구들 및 기능들에 대해 간단하게 소개하는 내용이라 코틀린을 잘 모르거나 막 시작하시는 분들이 가볍게 봐주시면 좋을 것 같네요. 개요 스프링 기반 프로젝트에서 코틀린을 사용하더라도 아래와 같이 기존에 사용하던 테스트 프레임워크인 Junit, Assertion, Mockito 등은 동일하게 사용할 수 있습니다. 초기 코틀린에 익숙하지 않은 상태에서는 관련 경험이 없어 위와 같은 형태로 Junit, AssertJ, Mockito를 사용해 테스트를 작성했습니다. 하지만 코틀린에 익숙해질수록 테스트 코드 내에서 코틀린 스타일로 코드를 작성할 수 없어 비즈니스 코드와 테스트 코드 간에 괴리가 느껴졌습니다. 아래에서 코틀린에서 Junit, AssertJ, Mockito를 사용해 테스트를 작성하는 경우의 문제점에 대해 자세히 다루고, 코틀린 진영에서 많이 사용되는 테스트 도구인 Kotest 및 Mockk 등에 대해 알아보겠습니다. 코틀린 DSL과 코틀린 스타일의 테스트코드 코틀린에서는 아래와 형태와 같은 DSL(Domain Specific Language) 스타일의 중괄호를 활용한 코드 스타일을 제공합니다. 코틀린 내부에서 제공하는 Standard library 대부분도 DSL을 이용해 작성된 것을 볼 수 있습니다. * Type safe builders * Kotlin Standard Library * Kotlin Scope Functions (let, also, apply, run ..) 기존에 사용하던 Junit과 AssertJ, Mockito를 사용하면 Mocking이나 Assertion 과정에서 코틀린 DSL 을 활용할 수 없습니다. 비즈니스 로직을 코틀린 DSL을 이용해 작성하더라도 테스트에서 예전 방식의 코드를 작성해야 하다 보니 코틀린에 익숙해질수록 테스트 작성이 어색해지게 됩니다. Kotest나 Mockk와 같은 도구들을 사용하면 아래처럼 코틀린 DSL과 Infix를 사용해 코틀린 스타일의 테스트 코드를 작성할 수 있습니다. 코틀린 진영의 테스트 도구들 위의 문제점을 해소하고 코틀린 DSL을 활용한 코틀린 스타일 테스트 코드 작성을 돕는 도구를 몇 가지 소개하겠습니다. KOTEST 코틀린 진영에서 가장 많이 사용되는 테스트 프레임워크입니다. 코틀린 DSL을 활용해 테스트 코드를 작성할 수 있으며 아래와 같은 기능들을 포함하고 있습니다. * 다양한 테스트 레이아웃(String Spec, Describe Spec, Behavior Spec 등) 제공 * Kotlin DSL 스타일의 Assertion 기능 제공 Kotest를 사용하기 위해서는 아래와 같은 설정 / 의존성 추가가 필요합니다. test { useJUnitPlatform() } dependencies { testI

안녕하세요? 저는 직방홈 파트에서 아파트의 커뮤니티 시설 예약시스템을 담당하고 있는데요, 오늘은 저희의 프로젝트에서 Java mocking framework인 Mockito을 어떻게 사용하고 있는지에 대해 이야기해보려고 합니다.“ Tasty mocking framework for unit tests in Java ”Mockito 공식 페이지에 있는 소개 글 입니다. 이 한 줄로 모든 게 설명이 되는데요, Mockito는 자바에서 단위테스트를 하기 위해 Mock을 만들어주는 프레임워크입니다. JUnit위에서 동작하며 Mock이 필요한 테스트에 직관적으로 사용할 수 있도록 만들어졌습니다. JetBrains에서 공개한 2020년도 개발자 에코시스템 현황 인포그래픽 자료를 보면 유닛 테스트를 사용하는 개발자의 43%가 Mockito를 사용한다고 합니다. 그리고 (좀 오래된 자료이긴 하지만 ) StackOverflow community에서도 Mockito가 Java를 위한 최고의 mocking framework로 최다 투표를 받기도 했습니다.Mockito는 아래와 같은 장점들이 있습니다.깔끔하고 간단한 API를 제공하여서 아름다운 테스트 코드를 작성할 수 있습니다.Mockito로 작성된 테스트 코드들은 읽기 쉽고 에러가 발생 시 깔끔하게 생성된 에러를 확인할 수 있습니다.테스팅 툴 뿐만 아닌 모든 Java 라이브러리 Top 10안에 드는 라이브러리 입니다.먼저 배경을 설명해 드리면, 저희 프로젝트에서는 Spring Rest Docs를 사용하여 현재 배포가 되어 동작하고 있는 API와 API 문서를 동일하게 관리하고 있습니다. Spring Rest Docs는 작성한 테스트 코드들이 모두 성공을 해야 문서가 생성되는데, 이러다 보니 모든 컨트롤러에 대해서는 테스트 커버리지가 100%가 되지만 컨트롤러 테스트 코드에서 동작하지 않는 서비스 코드는 테스트가 되지 않아 서비스 코드의 테스트 커버리지가 상대적으로 낮은 문제가 있었습니다. 이런 상황에서 서비스 로직의 테스트 코드가 필요하다는 공감대를 형성하고, 개선하기 위해 앞으로 코드 수정이 있는 서비스의 테스트 코드를 작성하여 테스트 커버리지를 100%로 끌어올리자! 라는 목표를 정하게 되었습니다.컨트롤러 테스트 -> 통합 테스트서비스 테스트 -> 단위 테스트이런 느낌으로 테스트 코드를 작성하고 있는데요, (갈 길이 아직 한참 머네요…..) 작성하다보니 문제가 발생했습니다. 하나의 메서드를 테스트하는데 필요한 정보들이 너무 많았습니다. 예를 들면 헬스장 1개월 이용권을 예약 취소하는 메서드를 테스트한다고 가정해 봅시다.헬스장 1개월 이용권의 정보헬스장 1개월을 예약한 이용자의 정보이용자가 헬스장 1개월을 예약한 정보이 세 가지 정보가 있어야 예약 취소라는 동작을 할 수 있습니다. 이렇게 데이터간에 의존성을 갖게되니 DB에 테스트를 위한 데이터를 생성하여 넣어두어도 DB에서 데이터를 가져올 때 테스트 환경에 따라 각각 다른 데이터가 조회되는 경우도 생기고, 다른팀과 같이 동작 테스트를 함께 하면 데이터가

모바일 애플리케이션 개발자들 사이에서 테스트 코드가 뜨거운 감자 인 것은 반박 불가능한 사실입니다. 안드로이드 애플리케이션을 개발할 때 테스트 코드는 어떤 코드에 대해서 얼마나 작성되어야 할까요? 사용자의 입력에 따라 원하는 행동을 하고, 원하는 뷰가 노출되는지를 확인하는 것 정도까지가 테스트 코드로 검증해야 하는 영역이라 생각할 수도 있고, HTTP API 통신 후 응답 값의 성공 및 실패 여부에 따른 값을 올바르게 처리하는지 확인하는 것까지가 테스트 코드가 검증해야 할 영역이라고 생각할 수도 있을 거예요. 테스트 코드 없이 작성된 과거 코드를 변경하게 될 때 테스트 코드를 작성해야 할지, 말지에 대한 고민도 다들 한 번씩은 해 보셨을 테고요. 서비스의 규모와 구조에 따라 다양한 답이 존재하겠지만, MVP 패턴과 Clean Architecture를 사용하는 뱅크샐러드 안드로이드 팀은 다음과 같은 코드에 대해서는 테스트 코드가 작성되어야 한다고 생각했어요. 수정/변경되는 모든 기능에 대해 반드시 테스트 코드를 작성한다. Presenting logic(MVP 구조 중 Presenter가 담당하는 역할)에 대한 검증은 필수적이며, View에 대한 테스트를 꼭 작성할 필요는 없다. 안드로이드 프레임워크나 UI 관련한 테스트 코드는 작성 및 실행에 있어 상대적으로 어려움과 번거로움이 존재한다고 판단 MVP에서 View를 아주 수동적으로 작성할 경우 View에 대한 테스트 코드를 작성하는 게 큰 효용이 없음 (어쩔 수 없이) View에 Presenting logic이 포함되는 경우에는 아래의 방법으로 테스트 코드를 작성한다. Instrumented test를 작성한다. View로부터 Presenter로 presenting 로직을 분리하는 리팩토링을 수행하며, 이에 대한 Presenter 테스트 코드를 작성한다. 관리되지 않던 기존 코드에 대한 테스트 코드 위와 같은 코드에 대한 변경이 있는 경우, 해당 변경으로 인해 영향받는 코드에 대한 테스트 코드는 필수적으로 작성한다. 이 코드가 3번 케이스에 해당하는 경우, 3-1, 3-2의 방법을 따른다. 수정/변경되는 모든 기능 수정/변경되는 모든 기능이란 어느 범위까지를 지칭할까요? 뱅크샐러드 안드로이드 팀에서는 새로운 기능 배포로 새로운 파일이 추가된 경우, 기존 파일에 일부 동작이 추가된 경우, 코드를 수정함으로써 기존 동작과 다른 동작이 되는 경우를 모두 추가되는 모든 기능 영역이라 보았어요. 즉, 변경된 코드가 한 줄이더라도 이로 인해 마땅히 수행할 기능이 달라졌다면 테스트 코드를 필수적으로 작성하는 것이죠. 서비스 장애를 최소화 하기 위해서, 클라이언트 개발자가 가장 적극적으로 할 수 있는 일은 바로 자동화된 테스트 작성입니다. 배포 주기가 빨랐던 우리 서비스는 더욱 위험한 상태였고, 실제로 테스트 코드가 없던 부분에서 장애가 나서 핫픽스-핫픽스의 핫픽스를 쳐야 했던 경험도 더러 있었어요. 이러한 위험을 통해 안드로이드 팀은 우리가 지킬 수 있는 최소한이자 최대한인 테스트 코드에 대해 날카롭

LINE Engineering Blog를 찾아주신 여러분, 안녕하세요? 오늘은 두 명이 공동으로 작성한 포스팅입니다. 저희 소개 먼저 드리겠습니다. LINE에서 게임 플랫폼 개발을 맡고 있는 Kagaya와 동영상 생중계 서비스 LINE LIVE의 Android 앱 개발을 맡고 있는 Akira입니다. 여러분은 Kotlin을 쓰고 계신가요? Kotlin은 JVM에서 돌아가는 정적 타입 프로그래밍 언어입니다. 현재 IntelliJ나 Android Studio 같은 IDE로 유명한 JetBrains사의 주도로 개발되고 있습니다. 작년 Google I/O에서 Android용 공식 개발 언어로 채택되어 화제가 됐었죠. 작년에 Engineering Blog에서도 LINE Creators Studio 개발에 사용하는 Kotlin 소개라는 글에서 Android 앱 개발에 Kotlin을 사용하고 있다고 소개한 바 있습니다. LINE에서는 신규 앱은 물론 기존 앱도 적극적으로 Kotlin으로 전환, 리팩터링하는 작업이 한창 진행 중입니다. 메시징 서비스를 제공하는 LINE 앱을 비롯, LINE LIVE나 LINE Creators Studio, AI 어시스턴트의 Clova용 앱 등 많은 Android 앱에서 Kotlin을 도입하고 있습니다. 서버사이드 개발에서도 팀별로 조금씩 Kotlin을 도입하고 있는데요. 이번 포스팅에서는 아래 두 가지 이야기를 통해 서버사이드 Kotlin에 관한 노하우와 유스케이스를 공유할까 합니다. 군데군데 Android 개발과 겹치는 내용도 나옵니다. Kagaya가 담당하는 LINE GAME 플랫폼의 Kotlin 이용 현황 이야기(#kotlin-at-line-game) LINE 사내 Clova Skill Award에 저희 둘이 팀으로 참가해서 Kotlin으로 영광의(?) 최우수상을 수상한 이야기(#kotlin-at-clova-skill-award) Android 앱을 개발하시는 분들도 이번 기회에 Kotlin으로 서버사이드 개발에 도전해 보시는 건 어떨까요? 시작하기 어렵지 않으실 겁니다. LINE에서 개최하는 개발 콘테스트 LINE BOOT AWARDS 2018에서도 우승 상금 1000만 엔을 걸고 많은 참여를 기다리고 있습니다. Kotlin으로 꼭 한번 도전해 보세요! LINE GAME 플랫폼에서 서버사이드 개발에 사용된 Kotlin LINE GAME의 많은 게임들은 외부 개발사나 계열사의 게임 스튜디오에서 제작되고 있습니다. 그들이 게임을 개발할 때 본질이라 할 수 있는 게임 로직 개발에만 더욱 전념할 수 있도록, LINE GAME 플랫폼에서 인증, 소셜 그래프 같은 기본적인 기능이나 프로모션 기능, 커뮤니케이션 관련 기능(사용자 타게팅, 공지 띄우기, 게임 내 게시판/채팅) 등을 제공하고 있습니다. LINE DEVELOPER DAY 2017에서 저희가 하는 일의 일부를 소개드렸었습니다. 플랫폼이라는 특성상 독립적인 구성 요소가 많습니다. 그래서 신규 개발을 스크래치부터 시작하는 경우가 많으며, 그 중 일부는 Kotlin을