1. 테스트 이론

[Devik0213]

Test

원칙1

의존는 주입받는다.

46

의존성주입을, 자체생성으로하지말자. 아래와같이 생성자에서서 생성해서넣어라.

49~50

UI/View에서 데이터를 참조하지 않기위해, DI를 사용하면 좋다. Domain Layer에서의 작업을 해야한다. 테스터블하려면, 자연적으로 Clean 아키택쳐로 바뀜

51 ~ 54

Static Class (주입불가, 테스트불가)

• static 을 일반클래스로 변경해서 사용하면됨.
• util 이나 object 를 어떻게 테스트해야합니까. 가령, DataObserver 의 자체테스트를 만들어서, IssueCreatePresenter 에 대해서만 집중한다.

55 : 원칙2

안드로이드의존동작은 Wrapping 한다.

• context로부터, context가 필요한 데이터는 모두 wrapping 한다.
• !! context를 끊어내고해야한다. = activity 에서 테스트 불가네? 그럼 presenter/viewmodel 에 비즈니스 로직을 넣어두고 테스트해야한다.

58

view interface로 wrapping 해서 검증해야함. respository 도 interface로 wrapping 해야한다. SDK Method / UI / DB, API 을 이용한 비즈니스로직을 검증하는게 우리의 목적이다.

63~74. 원칙3

모든동작은 프레젠터로 통한다. 최대한 유닛테스트영역으로 가져와서 UI테스트없이 하려고한다. ex) view.onClick { viewModel.onClickLogic(data) // 이런식으로 로직은 뷰모델에서 처리되도록하자. }

Mockito.verify(view).click 되면 된다. passive View 로직은 프레젠터로 보낸다.

78

Instrument Test

• UI test
• DB test

Instrument 를 통해, Context 를 얻어올수있다. 즉, Activity 도 테스트할수있다.

80

안드로이드테스트를 해야하면 하는데, 가급적 유닛테스트를 활용하자. ViewModel 을 통해서 테스트하고, Model 을 테스트할수있따.

최대한 유닛테스트로 테스트한다. (Testable Archt)

원칙 1,2,3

1. 의존클래스들은 주입받아야한다.
2. 안드로이드의존동작은 Wrapping 해서사용한다.
3. View 에서 직접 테스트하지말조, 모든 동작은 ViewModel에서 처리되도록해라.