가볍게 시작하는 Unit Test (with. XCTest)

이 글의 목표

뭐야? 테스트 이게 끝이야? 별거 없잖아?

 

테스트 세팅

위 사진처럼 처음 프로젝트를 만들때 Test를 포함했다면 상관 없지만, 테스트를 포함하지 않았거나

 

위 사진처럼 Target에 Test가 없을땐 직접 추가해주면 된다.

 

 

Test Target 추가하는 방법

위 사진 순서대로 Test Target을 추가하면 된다.

 

테스트 대상

우선 테스트 코드를 아주 쉽게 접근하기 위해 아주 간단한 테스트를 먼저 만나보자.

현재 애니또에서 사용하는 Entity중 하나인 RoomListItem 에 대한 테스트 코드를 작성해보겠다.

 

struct RoomListItem {
    /// 방의 고유 id값
    let id: Int
    /// 방 제목
    let title: String
    /// 현재 진행 상태
    let state: RoomStatus
    /// 현재 참여한 인원 (옵션)
    let participatingCount: Int?
    /// 방 참여 가능한 최대 인원
    let capacity: Int
    /// 시작 날짜 ex) 2023.09.12
    let startDate: String
    /// 종료 날짜 ex) 2023.09.16
    let endDate: String
}

extension RoomListItem {
    /// 시작날짜와 종료날짜를 ~을 포함한 String 형식으로 반환
    /// ex) 2023.09.12 ~ 2023.09.16
    var dateRangeText: String {
        return self.startDate + " ~ " + self.endDate
    }
    
    /// 시작 날짜가 오늘보다 과거인지
    var isStartDatePast: Bool {
        guard let startDate = self.startDate.toDefaultDate else { return true }
        return startDate.isPast
    }
}

extension에 선언된 두 변수중 dateRangeText 변수를 통해 테스트 코드를 익혀보자.

 

dateRangeText

해당 변수를 통해 “시작 날짜 ~ 종료 날짜” 형식이 제대로 리턴되는지를 확인하는 부분이다.

"2023.09.18 ~ 2023.09.22" // ✅
"2023.09.18~2023.09.22"   // ❌
"2023.09.18  ~  2023.09.22"   // ❌

~ 양 옆으로 띄어쓰기가 잘 되는지, 띄어쓰기가 두 번씩 되진 않는지 등 내가 원하는 모양이 아니라면 모두 테스트 실패 처리를 통해 테스트가 정상적으로 통과 되는지에 대해 알아보겠다.

 

 

테스트 파일 만들기

Test 폴더 내부의 원하는 위치에 파일을 만들어주면 된다.

원하는 파일명을 적고 Next를 눌러 생성하면 된다.

 

import XCTest

final class RoomListItemTest: XCTestCase {

    override func setUpWithError() throws {
        // Put setup code here. This method is called before the invocation of each test method in the class.
    }

    override func tearDownWithError() throws {
        // Put teardown code here. This method is called after the invocation of each test method in the class.
    }

    func testExample() throws {
        // This is an example of a functional test case.
        // Use XCTAssert and related functions to verify your tests produce the correct results.
        // Any test you write for XCTest can be annotated as throws and async.
        // Mark your test throws to produce an unexpected failure when your test encounters an uncaught error.
        // Mark your test async to allow awaiting for asynchronous code to complete. Check the results with assertions afterwards.
    }

    func testPerformanceExample() throws {
        // This is an example of a performance test case.
        self.measure {
            // Put the code you want to measure the time of here.
        }
    }

}

그럼 위와 같은 파일이 만들어 진다.

 

이 글은 테스트와 친해지기 위한 목적이기 때문에 부담스러운 코드들은 모두 지워주겠다.

 

import XCTest

final class RoomListItemTest: XCTestCase {
}

 

이 상태로 하나씩 테스트 코드를 만들어 보겠다.

 

@testable import

기존의 코드들은 Internal하게 작성되었다. 현재 Test 파일에선 기존에 작성했던 코드들에 접근할 수가 없다.

위 문제를 해결하기 위해서 @testable import 코드를 추가하면 기존 코드들에 접근할 수 있다.

import XCTest
@testable import Manito

final class RoomListItemTest: XCTestCase {
}

 

 

dateRangeText 검증하기

위에서 언급했던 dateRangeText 변수에 대해 테스트 코드를 작성해보겠다.

 

//  RoomListItem.swift

var dateRangeText: String {
    return self.startDate + " ~ " + self.endDate
}

1. 해당 변수가 실제 존재하는가
   RoomListItem 에 실제 dateRangeText란 변수가 없을수도 있다. 개발이 진행되다 해당 변수가 삭제 되었을 수도 있다. 그랬을때 테스트를 통해 발견하기 위함이다.
   
   
2. 올바른 값을 리턴하는가
   해당 변수로 부터 2023.09.18 ~ 2023.09.22 란 올바른 값이 들어왔을땐 테스트 성공하게 만들것이다.
   
   
3. 틀린 값이 들어왔을 때 틀렸다고 반응하는가
   2023.09.18 ~ 2023.09.22 처럼 ~ 앞 뒤로 띄어쓰기가 하나 더 있을땐 테스트를 실패하게 만들어보자.

 

Test Dummy 만들기

extension RoomListItem: Equatable {
    static let testRoomListItem = RoomListItem(
        id: 1,
        title: "테스트타이틀",
        state: "PRE",
        participatingCount: 5,
        capacity: 5,
        startDate: "2023.01.01",
        endDate: "2023.01.05"
    )
}

테스트에 사용할 dummy값을 미리 만들어뒀다. 추가적으로 Equatable 프로토콜을 채택했는데 그 이유는 두개의 RoomListItem을 Equal 값을 통해 비교하기 때문이다.

 

 

해당 변수가 실제 존재하는가

func test_dateRangeText_변수가_있는가() {
    let sut = RoomListItem.testRoomListItem
        
    let _ = sut.dateRangeText
}

위 두 줄로 실제 존재하는지 검증할 수 있다. dateRangeText가 없다면 빌드 에러가 발생한다. 이를 통해 해당 변수가 없음을 확인할 수 있다.

 

💡 TIP!

XCTestCase에선 Test를 실패하지 않는 이상 항상 성공으로 간주한다.
우리가 처음 UnitTest Class를 만들고 바로 테스트를 돌려봐도 테스트를 성공하는데 그 이유가 위의 이유랑 같다.

 

 

올바른 값을 리턴하는가

func test_dateRangeText_변수가_올바른값을_리턴가는가() {
    // given
    let sut = RoomListItem.testRoomListItem
    
    // when
    let dateRangeText = sut.dateRangeText
    
    // then
    XCTAssertEqual(dateRangeText, "2023.01.01 ~ 2023.01.05")
}

XCTAssertEqual 함수를 통해 테스트를 검증한다.

 

dateRangeText와 "2023.01.01 ~ 2023.01.05" 이 같은지 확인하고 같다면 테스트를 성공시킨다.

 

 

틀린 값이 들어왔을 때 틀렸다고 반응하는가

func test_dateRangeText_변수에_틀린값이_들어왔을때_실패하는가() {
    // given
    let sut = RoomListItem.testRoomListItem
    
    // when
    let dateRangeText = sut.dateRangeText
    
    // then
    XCTAssertNotEqual(dateRangeText, "2023.01.01  ~  2023.01.05")
}

~ 앞 뒤로 띄어쓰기가 한번씩 더 되어있을때 틀렸다고 인지하는지 체크한다.

위와는 반대되게 XCTAssertNotEqual 함수를 통해 확인한다.

dateRangeText 와 "2023.01.01 ~ 2023.01.05" 이 같지 않으면 테스트를 성공시킨다.

 

 

테스트 실행하기

테스트가 잘 되는지 확인하기 위해 Command + U 를 눌러 전체 테스트 코드를 실행해볼 수 있고,

각각의 함수 옆의 다이아몬드 버튼을 눌러서 실행할 수도 있다. class 옆의 버튼을 누르면 해당 class의 테스트 코드를 전부 실행한다.

 

 

신뢰 할 수 있는 코드

이를 통해 해당 dateRangeText 변수는 우리가 원하는대로 동작을 한다고 믿을 수 있게 되었다.

물론 더 다양한 상황에 대해 테스트 코드를 추가해도 좋다.

 

 

전체 코드

import XCTest
@testable import Manito

final class RoomListItemTest: XCTestCase {
    func test_dateRangeText_변수가_있는가() {
        let sut = RoomListItem.testRoomListItem
        
        let _ = sut.dateRangeText
    }
    
    func test_dateRangeText_변수가_올바른값을_리턴가는가() {
        // given
        let sut = RoomListItem.testRoomListItem
        
        // when
        let dateRangeText = sut.dateRangeText
        
        // then
        XCTAssertEqual(dateRangeText, "2023.01.01 ~ 2023.01.05")
    }
    
    func test_dateRangeText_변수에_틀린값이_들어왔을때_실패하는가() {
        // given
        let sut = RoomListItem.testRoomListItem
        
        // when
        let dateRangeText = sut.dateRangeText
        
        // then
        XCTAssertNotEqual(dateRangeText, "2023.01.01  ~  2023.01.05")
    }
}

 

 

마치며

최대한 쉽고 간단하게 설명하고자 작성했는데 의도와 맞게 작성되었는지 잘 모르겠다.

나도 처음엔 테스트 코드를 어렵게만 생각했고 아직은 할 단계가 아니라 생각했다. 다른 기능을 개발해야하고 수정해야할 부분들이 많았기 때문이다. 하지만 프로젝트가 진행되면 진행될 수록 테스트 코드의 필요성을 많이 느꼈다. 예상치 못하게 동작하는 코드들을 만나기 시작했을때 굉장히 당황스러웠다. 크게 건드리지 않았는데, 서로 엮어 문제를 발생시킨 것이었다. 이를 겪고나니 각각에 대해 안전장치가 있었으면 좋겠다고 생각했고, 그에 대한 해답이 테스트 코드라 생각했다. 내가 작성한 코드를 의심하지 않게끔 만들어주고, 든든하게 만들어주는 것 같다.

 

위 예시를 보고 테스트 코드를 각자의 프로젝트에 살짝이라도 적용해보면 좋겠다. 각각의 Entity나 Model에 위 상황과 비슷한 변수들이 하나쯤은 있을텐데 그걸로 아주 간단한 테스트 코드라도 만들어 본다면 한 발짝 앞으로 나아가는데에 조금은 도움이 될 것 같다.

 

 

 

 

 

참고 자료
https://www.avanderlee.com/swift/unit-tests-best-practices/