잘못된 테스트의 예시

class LetsGitHubSearchTests: XCTestCase {

    func testSearch_searchGitHub() {
        // given
        let expectation = XCTestExpectation()
        XCTWaiter().wait(for: [expectation], timeout: 10)
        
        RepositoryService.search(
            keyword: "RxSwift") { result in
                expectation.fulfill()
                XCTAssertEqual(result.isSuccess, true)
                XCTAssertEqual(result.value?.items.contains {
                    $0.name == "RxSwift"
                }, true)
            }
    }
}

• 잘못된 이유
  • RepositoryService.search() 함수는 외부 사이드이펙트로부터 분리되어 있지 않아 있다. 그래서 네트워크에 의존적인 테스트가 되어 순수한 비즈니스 로직만을 위한 테스트가 불가능 하다.

→ 그렇기 때문에 테스트 환경에서 사용하는 NetworkManager와 실제 Production 환경에서 사용하는 NetworkManager를 구분해야한다. 이것을 하기 위해 의존성 주입을 해줘야한다.

View Test

view test는 layout test와는 별개로 상태에 따라 UI속성이 변하는 경우에만 그 속성을 테스트하면 된다. 대표적인 예시가 activity indicator인데, isAnimating 속성을 가지고 테스트하는 것이다. 이걸로 연습하다보면 감을 잡기 쉽다.

접근 제한자

private을 사용하게 되면 외부 접근이 불가능하기 때문에 테스트코드 작성이 불가능하다. 그렇다고 풀어서 internal로 쓰자고하니, OOP에 위배가 된다. 어떻게 해야할까?

→ 약간의 trade off가 필요하다. 테스트를 구현하기 위해서는 결국 접근제한자를 internal수준으로 올리고, 다른 방법으로 접근을 제한하도록 생각해봐야한다. 예를 들어, private하게 사용할 녀석은 _를 prefix로 붙여서 서로간의 컨벤션을 정해놓고 해결하는 방법도 있다.

Dummy, Fake, Stub, Spy, Mock

• Dummy: 단순 의미 없는 값
• Fake: 실제 구현은 Local DB인데, fake로 메모리 db로 바꾸어 놓은 형태
• Stub: 전달받고자 하는 데이터를 바꿔서 전달 받음
  • [ex] 실제로 하면 123이 내려오지만, Stub에서 456으로 구현을 바꿔치기함
• Spy: 어떤 메소드를 호출하거나 변수에 접근했을 때, 그 내용을 기록하는 것
• Mock: 모든 테스트 대역. Spy가 기록한 것과 Stub이 만든 가짜데이터를 가지고 검증까지 함. Mock데이터 자체가 테스트를 실패시킬 수 있다.(이 안에 Assert가 있다.)

여기까지 내용 Wrap up