차지

클래스를 테스트할 때 private 변수는 외부에서 참조가 되지 않기 때문에 테스트에서 역시 참조할 수 없습니다. 하지만 해당 필드를 접근 가능하게 변경하고, 접근해서 참조하는 방법이 있습니다. val field = className.javaClass.getDeclaredField("filed_name") field.isAccessible = true field.set(className, value) getDeclaredField 메서드로 참조합니다. isAccessible 값을 true로 지정해 접근을 허용합니다. filed.get 또는 filed.set 메서드로 접근합니다. filed.set의 매개변수로는 접근할 클래스와 set할 값을 입력합니다.

LiveData는 LifeCycle에 대응하기 때문에 set value, post value 둘 다 test 중에는 작동하지 않는다. @get:Rule var instantTaskExecutorRule = InstantTaskExecutorRule() test 코드에 위와 같은 룰을 추가해줘야 set value, post value를 인식한다.

Junit Test Android 에서 단위 테스트를 진행할 때에는 Junit 라이브러리를 사용합니다. 이 글은 Junit4 버전으로 작성했습니다. build.gradle에 코드를 추가하면 사용할 수 있습니다. dependencies { ... testImplementation 'junit:junit:4.+' ... } 테스트할 객체나 함수에 커서를 올리고 cmd(ctrl) + shift + T 단축키를 사용하면 테스트 파일을 생성하거나, 이미 존재한다면 테스트 파일로 이동합니다. @Test 어노테이션을 붙인 함수를 작성하면, 테스트를 진행할 수 있습니다. Test Annotation @Test 작성할 테스트 코드입니다. 함수 이름에는 여러가지 컨벤션이 있습니다. snake_case를 사용해서 Metho..

Test Double 실제 속성을 사용하기 힘든 상황에서 테스트 코드를 작성할 때 가상으로 만드는 속성입니다. 객체 간의 의존성이 강해 테스트를 하기 위해 생성할 객체가 많을 때 묶어서 대체할 수 있습니다. Dummy 존재하기만 하는 객체입니다. 구현이 포함되어 있지 않으며 매개 변수로 필요하지만 사용되지 않는 경우 주로 사용됩니다. Stub 짤막하게 구현한 객체입니다. 구현이 포함되어 있지만 직접 단순하게 작성하며 큰 구현을 작게 대체하는 용도로 사용됩니다. Fake 로직이 포함된 객체입니다. Stub에서 미처 작성못한 로직이 작성됩니다. Spy 객체를 관찰합니다. 사용 여부, 호출 여부 등을 기록하고 기록한 정보를 전달합니다. 행위 기반 테스트 동작이 수행됐는지 검증하는 테스트 방식입니다. 상태 검증..

Test Driven Development 테스트가 개발을 이끌어 나간다. 테스트를 먼저 작성해서 수시로 피드백을 받는 기법입니다. 항상 옳을까? 불확실성이 높다면 옳다고 할 수 있습니다. 처음 접하는 주제, 수시로 바뀌는 요구조건, 유지보수의 역할을 타인에게 넘겨야 할 경우 위와 같은 경우에 이롭습니다. 유지보수 비용, 버그가 줄어들고 가독성이 좋아지는 효과가 있습니다. 내가 작성하지 않은 코드를 수정할 때, 테스트에서 상세히 피드백을 받으며 진행할 수 있습니다. 그럼 무조건 써야되나? 미래의 유지보수를 대비하기에 좋지만, 당장의 성과가 더 중요할 때가 많습니다. 개발시간에 테스트 코드를 짜는 시간까지 더해져 효율이 좋지 않습니다. 도구와 규칙에 얽매이게 되는데, 애자일에 어긋나는 행위입니다. BDD?..