😫 생각보다 고생스러운 유닛테스트
드!디어! 유닛테스트를 도입하고 있다.
저번에 Hilt를 도입하는건 쉬운 편이었다.
일단 의존성 자체가 줄어드는 것이 바로바로 보이고, 쉬운 부분부터 해결하면 되는 것이기 때문에 재미도 있고..
근데 유닛테스트의 문제는 테스트를 하는 대상들이 상당히 난해한녀석들이라는것,
먼저 이미 내가 진행하는 프로젝트는 MVVM으로 진행하고 있기 때문에
테스트 대상이 코루틴이나, LiveData등 단순한 POJO가 아니다.
무한 구글링하고, 공홈도 찾아보아도.. 도저히 ... no...
그래서 이번에도 갓튜브의 도움을 받았다.
저번 Hilt에서는 Mitch의 도움을 받았지만 이번엔 Philipp Lackner님의 도움을 받았다.
Mitch랑도 친분이 있으신듯 한데..
아무튼, 많은 도움을 받아 드디어, FakeRepository하나 만들어 뷰모델을 유닛테스트했다.
🤯 배운 것들
안드로이드에서 테스트
Unit Test가 70% Integration Test가 20%, UI가 10%정도를 차지한다고 한다.
어쨋든 Unit Test는 각 Unit 별 테스트라면, Integration Test는 안드로이드 프레임 워크와 상호작용하는 테스트라고 한다. UI테스트는 실제 UI와 상호작용하는 테스트인데
솔직히 아직 Unit 테스트 단계밖에 경험해보지 못한 나는,, 잘 몰라용.
테스트 패키지의 의미
요 androidTest와 test의 차이는 바로...
JVM에서만 동작하는지와 실제 안드로이드 기기에서 동작하는지의 차이다.
그래서 androidTest에서 테스트를 진행하면, 가상머신이 켜진다거나, 연결된 실제 기기가 동작한다.
근데 왠만하면, test에서 할수있으면 test에서 할수 있는게 좋다고 한다.
왜일까??
필립님의 말씀에 의하면, 좋은 테스트는.
3가지를 만족해야한다. 는데!!!
자세한 설명은, 필립님의 유투브를 보도록 하자. ㅎ
결국 Speed가 중요하기 때문에 JVM에서 유닛테스트를 하는것이 좋다. 뷰-모델 테스트를 할때 실제로 네트워크 통신을 하지 않고, Fake한 구현체를 만드는 이유도 마찬가지라고 한다.
실제로 난 FakeRepo로 만든 유닛테스트만 완성한 참이다..
😀 그외
저번에 김영한님의 SpringFramework 강의를 듣고 알게된,
given, when, then의 패턴으로 테스트 케이스를 짯다.
궁금하면, 영한님의 spring 입문 강의를 들으면 알수 있다.ㅎ
진짜 재밌고 좋음. ㅎ
🏃 다음 단계로...
유닛테스트부터 다 해보고, Integration, UI 테스트까지 커버해보자..
TDD란 이런걸까..?
