[WWDC] Testing in Xcode: Introduction to XCTest

WWDC 영상은 여기를 클릭해주세요 ('-' э )Э

 

해당 세션에서는 크게 Introduction To XCTest, Test plans, Continuous integration workflows 이렇게 3가지 토픽에 대해 얘기하고 있습니다. 블로그에서는 마지막 토픽을 제외한 앞의 두 가지 내용에 대해서만 다루고자 하니 참고 부탁드립니다! (CI는 ... 나중에.. 커밍쑨 ε( ε ˙³˙)з ○º )

 

Introduction to XCTest

🧪 XCTest란 ?

Xcode에서 제공되는 자동화 테스트 프레임워크.

테스트를 설정하고 실행하는데 도움이 된다

 

❓ 근데 테스트는 왜 해야될까?

테스트는 코드에서 버그를 찾는데 도움이 되는 모든 프로젝트 개발의 중요한 단계이기 때문.

또한 테스트를 사용하여 요구 사항을 코딩할 수도 있음 (TDD를 얘기하는걸까나 .. 🤔)

 

⚠️ Test Pyramid

 

1. Unit Test (단위 테스트)

 

짧고 간단하며 매우 빠르게 실행됨.

모든 테스트의 기초가 되므로 모든 함수를 다룰 수 있도록 많은 단위 테스트를 작성해야 함.

피라미드의 기초이며 일반적으로 하나의 코드, 즉 함수를 검증하는 데 도움이 됨 (함수에 변수를 입력하고 예상되는 출력을 반환하는지 확인하는 방식)

 

2. Integration Test (통합 테스트)

 

서로 다른 컴포넌트가 함께 올바르게 작동하는지 확인하기 위해 개별 서브시스템 또는 클래스 클러스터를 대상으로 해야 함.

일반적으로 단위 테스트만큼 많은 통합 테스트가 필요하지 않음.

실행하는 데 시간이 조금 더 걸릴 수 있지만 한 번에 더 많은 앱을 테스트할 수 있음.

통합 테스트는 단위 테스트 위에 위치하는데, 이는 더 큰 코드 부분을 테스트하기 전에 개별 함수가 올바르게 작동하는지 확인해야 하기 때문.

코드의 더 큰 부분을 검증하는 데 사용됨.

 

3. User Interface Test

 

앱의 사용자 단계별 동작을 관찰함

이를 통해 앱이 실제로 사용자가 기대하는 대로 작동하는지 확인 가능.

UI 테스트는 실행하는 데 가장 오랜 시간이 걸리지만 모든 것이 올바르게 작동하는지 확인하는 데 필수적.

또한 앱의 UI가 더 자주 변경될 수 있기 때문에 UI 테스트는 더 많은 유지 관리가 필요.

 

🗂️ Types of XCTest

 

XCTest는 총 3개의 테스트 타입을 지원함

1) Unit Test(Unit & Integration) 2) UI Test(Blackbox Test) 3) Performance Test

오늘의 주제는 Unit Test & UI Test

🤔 How to start test in Xcode

 

Xcode 프로젝트에서 테스트를 시작하는 가장 쉬운 방법은 새 프로젝트를 시작할 때 유닛 테스트와 UI 테스트를 모두 포함하도록 선택하는 것 (기존 프로젝트에 추가하는 것도 가능)

Unit Test, UI Test 타겟과 기본 템플릿 코드가 자동으로 생성됨

 

// How to use XCTest

import XCTest
@testable import MyCounterApp

// 여기서 XCTestCase를 상속받고 있는 이유는 이를 상속받음으로써 Xcode가 해당 클래스 내부의 메서드들을
// 테스트할 때 사용할 수 있게 하기 위해서이다 !
class MyCounterTests: XCTestCase {
	
	func testIncrementCounter() {
		var counter = Counter()
		counter.increment()
		
		XCTAssertEqual(counter.value, 1, "Counter was not incremented: \(counter)")
	}
}

• 테스트 메서드 네이밍 규칙: 테스트 케이스로 사용하려는 각 메서드는 test라는 단어로 시작해야 하며, 그 다음에는 무엇을 할 것인지를 나타내는 이름을 지정해야함.
• Assertion API: 테스트 내부에서 assertion API는 소스 코드를 평가하고 유효성을 검사하는 데 사용됨. 이 경우 XCTAssertEqual은 주어진 처음 두 값을 비교하여 동일한지 확인함.
• SetUp, TearDown: SetUp 메서드는 각 테스트 케이스가 실행되기 전에 호출됨. 그런 다음 XCTest가 테스트 메서드를 실행하고 그 후에 tearDown을 사용하여 데이터 또는 앱의 전역 상태에 대한 변경 사항을 정리하여 테스트가 후속 테스트에 영향을 줄 수 있는 내용을 남기지 않도록 해야함.

Demo

Unit Test

// 요 메서드를 테스트해볼게요!(DistanceCalculator class의 instance 메서드)
func city(forName city: String) -> City? {
	return cities[city]
}

 

가장 먼저 DistanceCalculator 클래스를 테스트하기 위한 DistanceCalculatorTests 테스트 클래스를 생성.

class DistanceCalculatorTests: XCTestCase {

	func testCoordinatesOfSeattle() throws {
		// 먼저 테스트할 객체를 생성해준다.
		let calculator = DistanceCalculator()
		// city 메서드는 옵셔널 타입을 리턴하기 때문에 이때 옵셔널이 아니기 원하기 때문에 XCTUnwrap이라는
		// API를 활용한다! 
		// 그리고 이때 이 메서드는 에러를 throw할 수 있는 메서드이기 때문에 testCoordinatesOfSeattel
		// 메서드 자체도 에러를 던질 수 있는 throws 키워드를 붙여줘야한다.
		let city = try XCTUnwrap(calculator.city(forName: "Seattle"))

		XCTAssertEqual(city.coordinates.latitude, 47.61)
		XCTAssertEqual(city.coordinates.longitude, -122.33)
	}
}

var calculator: DistanceCalculator!

override func setUp() {
	super.setUp()
	calculator = DistanceCalculator()
}

override func tearDown() {
	calculator = nil
	super.tearDown()
}

func testSanFransicoToNewYork() throws {
	let distanceInMiles = try calculator.distanceInMiles(from: "San Fransico", to: "New York City")
	// 여기서 계산된 값은 2571.6947594 이런 소수점으로 나오는데 나는 어느정도 근사치에만 도달하면
	// 테스트를 통과시키고 싶기 때문에 이런 경우에는 accuracy 파라미터를 추가해서 근사치 정도를 조절할 수 있다!
	XCTAssertEqual(distanceInMiles, 2571, accuracy: 1)
}

 

두번째 테스트 메서드에서도 DistanceCalculator class를 테스트해야하기 때문에 객체를 생성해야함. 이때 첫번째 테스트 메서드와 객체를 생성하는 부분이 중복되는 것을 볼 수 있음

➡️ 클래스의 프로퍼티로 선언해서 중복된 코드를 줄일 수 있음. 그리고 각 테스트 케이스 전에 실행되는 setUp 메서드에서 초기화시켜주면 됨.

 

위의 두 테스트 메서드는 함수에 유효한 입력을 받고 유효한 입력이 반환되는지 확인하는 테스트.

 

이와 달리 오류도 올바르게 처리되는지 확인하고 싶은 경우도 테스트 작성이 가능함

func testCupertinoNotRecognized() {
	XCTAssertThrowsError(try calculator.distanceInMiles(from: "Cupertino", to: "New York City")) { error in
		XCTAssertEqual(error as? DistanceCalculator.Error, .unknownCity("Cupertino"))
	}
}

 

XCTAssertThrowsError를 통해 먼저 에러가 발생하고 있는지 확인하고, XCTAssertEqual로 기대한 오류인지 확인하는 것도 가능함.

 

UI Test

override func setUp() {
	// 주로 test가 fail했다는 것은 예상치못한 UI 상태를 맞닥뜨렸다는 것이다.
	// 더이상 상호작용이 불가능할 수 있기 때문에 continue하지 않도록 설정해줘야한다.
	continueAfterFailure = false
	app.launch()
}

func testMilesToParis() {
	// Discover tap 탭
	app.tabBars.buttons["Discover"].tap()
	// 초기 상태인 San Fransico label이 보여지고 있는지
	// isHittable: 해당 요소가 존재하는지 그리고 화면에 표시되는지를 확인
	XCTAssert(app.staticText["San Fransico"].isHittable)
	
	// 의도한 상황으로 앱의 상태를 변화시키기 위해 swipeLeft 실행
	let sfImage = app.images["san-fransico"]
	sfImage.swipeLeft()
	// 그 후에 원하는 정보들이 잘 보여지고 있는지 확인
	XCTAssert(app.staticTexts["Paris"].isHittable)
	XCTAssert(app.statictexts["5586 miles away"].isHittable)
}

 

테스트 코드를 작성하는 과정에서 원하는 UI 컴포넌트에 접근하고 싶으나 정확한 이름 혹은 식별자를 모르는 경우, 브레이크 포인트를 건 후 po 명령어를 통해서 현재 앱에 표시되고 있는 모든 컴포넌트에 대한 정보, 혹은 원하는 특정 타입에 대한 정보를 얻을 수 있음.

po app
po app.images

 

그리고 현재 테스트에서는 정적인 "5586 miles away"라는 텍스트를 찾고 있는데 만약에 테스트 하는 위치가 변경된다면 거리가 달라질 수 있기 때문에 mock data를 사용하거나 해당 데이터를 얻을 수 있는 위치에 있는 것처럼 테스트를 해야함.

 

Test Organization

 

위에서처럼 한 프로젝트에 Unit Test, UI Test를 추가하면 각각의 테스트 타겟이 추가됨.

테스트 타겟 내부에는 여러 테스트 클래스가 포함되고, 하나의 테스트 클래스 내부에는 여러 테스트 메서드가 존재함.

 

 

하지만 프로젝트 구조가 더 복잡해지면서 새로운 프레임워크가 추가되는 경우, 해당 프레임워크를 위한 테스트 타겟이 추가돼야한다. 

Swift package 또한 이미 테스트 타겟이 정의돼있을 것임. 

 

Code Coverage

테스트가 실제로 모든 소스 코드를 얼마나 잘 커버하는지 확인할 수 있는 방법이 바로 코드 커버리지.

테스트를 실행하는 동안 소스 코드의 각 줄이 실행된 횟수를 측정하고 시각화해줌.

 

타겟 내부의 존재하는 파일 별로 얼마나 테스트가 진행됐는지 한 눈에 확인하는 것도 가능하고

 

각 파일 별로 어떤 부분이 테스트 됐는지, 되지 않았는지, 테스트 하는 동안 각 코드가 몇 번씩 실행됐는지 모두 확인 가능.

 

Test의 중요성

• 만약 새로운 코드를 작성한 후 기존 테스트 코드가 코드의 변경 사항을 충분히 커버하지 못한다고 생각이 들면 다시 테스트 코드를 작성하는 것이 좋음.
• 테스트 코드는 일찍 작성할 수록 그 가치를 더 잘 활용할 수 있음.
• 소스 코드와 함께 진행되는 테스트를 갖고 있음으로써 새로운 작성되는 코드들을 더 신뢰할 수 있고 기대대로 작동함을 확인할 수 있음.
• 테스트는 지속적인 프로세스이며 앱의 상태를 유지하는 데 필수적이다!!