Feature/explore viewmodel 테스트 #34
Conversation
|
테스트명을 한글로써서 sonarqube에 Issue로 되었는데 |
모든 코드는 기본적으로 영어입니다. |
| @@ -38,5 +38,27 @@ data class FileInfo( | |||
| createdAt = LocalDateTime.now(), | |||
| lastModified = LocalDateTime.now() | |||
| ) | |||
|
|
|||
| val PDF_DUMMY = FileInfo( | |||
There was a problem hiding this comment.
테스트를 위한 코드는 테스트 패키지 또는 테스트 클래스 내에 작성해주세요.
실제 코드에 작성하면 불필요한 코드가 실제 바이너리에 포함되게 됩니다.
| import java.time.LocalDateTime | ||
| import java.time.ZoneId | ||
|
|
||
| internal class FileManager: IFileManager { |
There was a problem hiding this comment.
정답은 아닙니다만, 최근에 인터페이스에 I를 붙이지 않는 추세입니다.
아래와 같은 방식이 더 자주 보입니다.
interface FileManager
class FileManagerImpl : FileManager
| import java.time.LocalDateTime | ||
| import java.time.ZoneId | ||
|
|
||
| internal class FileManager: IFileManager { |
There was a problem hiding this comment.
사실 readPDFOrDirectory는 테스트가 불가능한 함수였습니다.
이처럼 테스트 가능한 설계에 대해 미리 고민하지 않으면 테스트 코드 작성시에 리팩토링을 해야하는 과정이 생깁니다. :)
이 경험을 통해 다음엔 더 효과적인 설계를 할 수 있도록 성장하기를 기대합니다.
| import org.junit.Test | ||
| import kotlin.test.assertEquals | ||
|
|
||
| class ExploreViewModelTest { |
There was a problem hiding this comment.
테스트 코드를 작성하다보면 코루틴 디스패처 정의나 Mockk 처리 등을 위한 코드가 중복이 됩니다.
그래서 이러한 것들을 Rule로 생성하고, 테스트 클래스를 위한 베이스를 만드는 것이 중복 제거와 생산성 향상에 좋습니다.
테스트코드 Rule에 대해서 학습해보세요.
There was a problem hiding this comment.
Testing Module을 만들어 dispatcher에 관한 룰을 만들었습니다
| @Before | ||
| fun setup() { | ||
| Dispatchers.setMain(testDispatcher) | ||
| recentRepository = mockk(relaxed = true) |
There was a problem hiding this comment.
Mockk는 어노테이션을 제공합니다.
before 함수에 매번 mockk 코드를 작성하지 않고, 필요한 객체의 선언과 함께 모킹을 할 수 있습니다.
| @Before | ||
| fun setup() { | ||
| Dispatchers.setMain(testDispatcher) | ||
| recentRepository = mockk(relaxed = true) |
There was a problem hiding this comment.
반환값을 기본값으로 초기화 시키는 겁니다
| } | ||
|
|
||
| @Test | ||
| fun `Init intent 경로를 통한 파일 초기화`() = testScope.runTest { |
There was a problem hiding this comment.
테스트코드에서 코루틴을 사용할 때 StandardTestDispatcher, testScope가 필요한 이유가 무엇일까요?
There was a problem hiding this comment.
그냥 runTest 사용하면 될 것 같습니다
|
|
||
| viewModel.handleIntent(ExploreUiIntent.Init(path)) | ||
|
|
||
| advanceUntilIdle() |
There was a problem hiding this comment.
advanceUntilIdle, runCurrent 등, 코루틴을 테스트할 때 사용되는 몇 가지들이 있습니다.
각각의 역할이 무엇인지 잘 이해하고 사용하시길 바랍니다.
There was a problem hiding this comment.
비동기 작업수행시 기다렸다 동작하는 것인데
delay가 아닌 모든 비동기 작업에서 수행해야 한다고 착각한것 같습니다
|
|
||
| advanceUntilIdle() | ||
|
|
||
| viewModel.sideEffect.first().let { |
There was a problem hiding this comment.
사소한 부분이지만, 어떤 객체의 생성과 함께 이어지는 검증을 해야할 때는 also가 용도에 좀 더 맞습니다만, 팀마다 견해가 다를 수 있습니다.
There was a problem hiding this comment.
아 스코프 펑션을 너무 신경안쓰고 사용한것 같습니다
| } | ||
|
|
||
| @Test | ||
| fun `Init intent 경로를 통한 파일 초기화`() = testScope.runTest { |
There was a problem hiding this comment.
테스트코드의 명은 AAA 패턴 또는 Given-When-Then 을 따르면 이해하기 좋습니다.
특히, 나중에 kotest를 사용하시게 되면 더 강력하게 Given-When-Then을 따르게 될 수 있습니다.
|
|
||
| internal class ExploreViewModel( | ||
| private val recentRepository: RecentRepository, | ||
| private val fileManager: FileManager, | ||
| private val fileManagerImpl: FileManagerImpl, |
There was a problem hiding this comment.
ViewModel의 의존성은 FileManager 인터페이스로 두고, 주입되는 클래스를 구체클래스인 FileManagerImpl로 하는 것이 의존성 주입 목적에 맞을 것 같습니다.
There was a problem hiding this comment.
아 이름 바꾸면서 바꼇네요 수정하겠습니다
| @@ -27,16 +25,16 @@ class ExploreViewModelTest { | |||
|
|
|||
| private lateinit var viewModel: ExploreViewModel | |||
| private lateinit var recentRepository: RecentRepository | |||
| private lateinit var fileManager: FileManager | |||
| private lateinit var fileManagerImpl: FileManagerImpl | |||
There was a problem hiding this comment.
ViewModel의 의존성을 FileManager 인터페이스로 변경하고 테스트 클래스도 동일하게 변경해주세요.
|
📝작업 내용