iOS에서 가짜 데이터를 사용하여 테스트하는 방법

고품질 소프트웨어를 제공하고 회귀를 피하려면 모든 iOS 응용 프로그램에서 단위 테스트를 구현해야합니다.
모의 객체는 실제와 동일한 API를 사용하여 가짜 객체를 만드는 단위 테스트 기술입니다.
이 기사는 iOS 앱에서 가장 많이 발생하는 시나리오에 대해 가짜 데이터를 사용하고 단위 테스트를 작성하는 방법에 대한 모범 사례를 제공하기 위해 작성되었습니다.

단위 테스트를 작성할 때 항상 응용 프로그램 대상의 실제 데이터를 변경하지 말고 테스트 목적으로 만 가짜 데이터를 사용해야합니다.

다음 부분에서는 일반적으로 사용되는 iOS API에 가짜 데이터를 사용하여 테스트를 작성하는 방법에 대해 설명합니다.

사용자 기본값

소프트웨어 개발에서 항상 객체의 종속성을 줄이는 것이 좋습니다. 가장 좋은 경우의 의존성은 그것을 사용하는 클래스에 주입해야합니다.

그러나 실제 iOS 개발 시나리오를 확인하면 거의 모든 프로젝트가 데이터를 저장하거나 검색하기 위해 API를 직접 호출하여 UserDefaults를 사용합니다.

따라서 API를 프로토콜로 추상화하는 대신 UserDefaults를 테스트하기위한 실용적인 솔루션을 제공하려고합니다.

UserDefaults에 두 가지 새로운 기능을 만들 수 있습니다

단위 테스트 대상에서 응용 프로그램 데이터를 변경하지 않는 것이 좋습니다. 따라서 테스트 대상에 대해 사용자 데이터를 저장하는 다른 장소를 만들어야합니다.

이 경우 suiteName — testDefaults를 사용하여 UserDefaults의 새 객체를 초기화하여 표준 UserDefaults와 완전히 독립적입니다.

UserDefaults를 사용하는 간단한 테스트를 작성해 봅시다.

이 데이터는 기본적으로 테스트 용으로 만 사용되므로 데이터를 응용 프로그램 파일에 남겨 두지 말아야합니다. 따라서 테스트를 마친 후에이 스토리지를 삭제하는 기능을 생성합니다.

물론이 데이터를 제거하기에 가장 좋은 장소는 단위 테스트 클래스에서 tearDown 함수입니다.

Singelton 객체

Singletons Objects는 많은 API의 iOS에서 많이 사용되며 NSFileManager, NSApplication, UIApplication 및 기타 여러 곳에서 찾을 수 있습니다.

싱글 톤을 테스트하는 방법을 아는 것은 iOS 개발자에게 유용한 정보입니다.

이 예에서는 Apple의 iAd 프레임 워크를 사용합니다. 광고 속성 세부 정보 요청에 대한 실제 데이터 대신 로컬 JSON 응답을 얻기 위해 파일을 만듭니다.

iOS의 멋진 기능은 신속한 확장 기능을 통해 사전 정의 된 API에 새로운 기능을 추가 할뿐만 아니라 자체 맞춤형 프로토콜을 준수 할 수 있다는 것입니다.

AdvertismentClient 프로토콜을 정의하겠습니다

그런 다음 기본 ADClient와 가짜 광고 클라이언트 모두 다음과 같이이 프로토콜을 준수합니다.

그런 다음 의존성을 다음 중 하나로 변경합니다.

전용 var adClient : AdvertismentClient = ADClient.shared ()

또는

전용 var adClient : AdvertismentClient = MockAdClient ()

다음과 같이 사용하십시오

이러한 방식으로 실제 애플리케이션 사용 시점과 테스트 시점을 쉽게 결정할 수 있습니다. 실제 테스트 대상에서 단위 테스트 또는 API 호출 여부에 따라 다릅니다.

핵심 데이터

코어 데이터는 여전히 데이터 캐싱을 위해 iOS에서 많이 사용됩니다. 핵심 데이터 엔터티를 테스트하는 것은 까다로울 수 있습니다. 아래에서는 핵심 데이터 서비스 구성 및 가짜 데이터 구성의 모범 사례를 설명합니다.

일반적으로 대부분의 경우 프로젝트 전체에서 핵심 데이터 코드를 사용하지 않고 데이터베이스에서 특정 데이터를 가져 와서 작성하는 서비스 클래스를 작성하는 것이 좋습니다.

여기에는 주로 두 가지 이점이 있습니다.

  • 나중에 핵심 데이터를 다른 데이터베이스로 바꾸려면 한 클래스에서만 변경해야 할 경우 사용중인 기본 데이터베이스와 분리됩니다.
  • 이를 통해 어떤 CoreDataStack을 사용할 것인지 또는 다른 프레임 워크에서 필요할 수있는 다른 설정을 쉽게 결정할 수 있습니다.

우리는 CoreDataStack 프로토콜을 생성 한 다음이 프로토콜을 따르는 두 개의 CoreDataStack (MainCoreDataStack 및 하나의 MockCoreDataStack)을 생성합니다.

그런 다음 응용 프로그램 대상 또는 단위 테스트 대상에서 사용 중인지에 따라 DatabaseService를 초기화 할 수 있습니다.

우리의 주요 핵심 데이터 스택은 다음과 같은 기본 설정을 갖습니다.

단위 테스트를 할 때는 항상 테스트 할 때 현재 '실제'개체의 상태를 변경하지 않아야합니다.

따라서 가짜 핵심 데이터 엔터티를 만들려면 별도의 영구 저장소가 있고 메모리 내 저장소 유형 구성을 사용해야 변경 사항이 디스크에 저장되지 않고 현재 유지되는 데이터와 완전히 분리됩니다.

이제 MainCoreDataStack을 사용하여 기본적으로 초기화되는 데이터베이스 서비스를 작성할 수 있습니다.

테스트 클래스에서 가짜 데이터 스택으로 초기화 할 수 있습니다

이제 다음과 같이 몇 가지 간단한 테스트를 작성할 수 있습니다.

이 방법을 사용하면 응용 프로그램 대상에 의해 저장된 데이터에 영향을주지 않고 DatabaseService를 쉽게 테스트 할 수 있습니다.

네트워크 요청

네트워크 계층을 테스트 할 때 프로토콜 지향 접근 방식을 사용하여 프로토콜을 생성하고 실제 NetworkService 및 MockNetworkService에 의해 프로토콜을 준수한 후 실제 또는 모의 서비스를 사용하여 종속성을 주입 할 수 있습니다.

이 기사에서는 조롱과 스터 빙을 더 잘 처리하는 OHHTTPStubs라는 멋진 오픈 소스 라이브러리를 사용합니다.

이 라이브러리의 장점은 유명한 iOS 네트워킹 라이브러리 Alamofire와 잘 작동한다는 것입니다.

OHHTTPStub을 사용하면 스터 빙 네트워크 요청이 매우 쉽습니다. 사전에 사용자 정의 응답을 제공하여 특정 경로 또는 호스트에 대한 응답을 바꿀 수 있습니다.

그 후에 앱에서 다음 URL로가는 모든 요청은 대신 사용자 정의 응답을 반환합니다.

tasksURL = URL (문자열 :“https://jsonplaceholder.typicode.com/todos ")!

사용자 정의 응답에 대해 정말 멋진 점은 단순히 응답에 오류를 반환하여 오류 및 엣지 케이스가 올바르게 처리되는지 쉽게 테스트 할 수 있다는 것입니다.

응답을 위해 사전을 수동으로 구축하는 것은 훌륭한 기능이지만 많은 속성을 가진 큰 JSON 데이터를 반환하려는 경우 테스트 클래스에서 지저분하고 유지 관리하기가 어려울 수 있습니다.

이 경우 JSON 파일을 사용하여 다음과 같은 응답을 스텁 할 수 있습니다.

이제 앱이 요청을 보낼 때마다 파일에 저장 한 myResponse.json 파일에서 응답을받습니다.

애플리케이션과 함께 이러한 파일을 제공하면 쉽게 볼 수 있기 때문에 민감한 정보를 이러한 JSON 파일에 저장하지 마십시오.

자세한 내용은 보안 주제에 대한 내 기사를 확인할 수 있습니다.

결론적으로

회귀를 최대한 피하고 완벽한 응용 프로그램을 제공하려는 경우 응용 프로그램의 단위 테스트가 필수적입니다.

이 기사에서는 iOS 개발 중에 발생하는 일반적인 사례에 대한 테스트를 제공하는 방법에 대해 설명했습니다.

UserDefaults, Singeltons, Core Data 및 Network Requests를 테스트하는 방법에 대해 논의했습니다.

이 기사가 마음에 드 셨다면 박수를 보내서지지를 보여주십시오.

iOS 개발자 기술을 한 단계 끌어 올릴 수있는 더 많은 기사를 보려면 저를 따르십시오.

질문이나 의견이 있으시면 여기에 메모를 남기거나 arlindaliu.dev@gmail.com으로 이메일을 보내주십시오.