วิธีทดสอบโดยใช้ข้อมูลปลอมบน iOS

เพื่อให้ซอฟต์แวร์ที่มีคุณภาพสูงและหลีกเลี่ยงการถดถอยการใช้การทดสอบหน่วยเป็นสิ่งจำเป็นสำหรับทุก ๆ แอปพลิเคชัน iOS
การจำลองวัตถุเป็นเทคนิคในการทดสอบหน่วยที่สร้างวัตถุปลอมโดยใช้ API เดียวกับวัตถุจริง
บทความนี้มีประโยชน์เพื่อให้คุณมีแนวทางปฏิบัติที่ดีที่สุดเกี่ยวกับวิธีการใช้ข้อมูลปลอมและเขียนการทดสอบหน่วยสำหรับสถานการณ์จำลองที่เกิดขึ้นมากที่สุดในแอพ iOS

เมื่อเขียนการทดสอบหน่วยเราควรหลีกเลี่ยงการเปลี่ยนแปลงข้อมูลจริงของเป้าหมายแอปพลิเคชันและใช้ข้อมูลปลอมเพื่อการทดสอบแทน

ส่วนต่อไปนี้จะกล่าวถึงวิธีการเขียนการทดสอบโดยใช้ข้อมูลปลอมสำหรับ iOS API ที่ใช้กันทั่วไป

ค่าเริ่มต้นของผู้ใช้

ในการพัฒนาซอฟต์แวร์เป็นแนวปฏิบัติที่ดีในการลดการพึ่งพาของวัตถุ การอ้างอิงในกรณีที่ดีที่สุดควรถูกแทรกลงในคลาสที่ใช้งาน

แต่ถ้าเราตรวจสอบสถานการณ์การพัฒนา iOS ในชีวิตจริงเกือบทุกโครงการใช้ UserDefaults โดยเรียกมันว่า API โดยตรงสำหรับการจัดเก็บหรือดึงข้อมูลใด ๆ

ดังนั้นเราจะพยายามเสนอวิธีแก้ปัญหาที่เป็นประโยชน์สำหรับการทดสอบ UserDefaults แทนการสรุป API ของมันด้วยโปรโตคอล

เราสามารถสร้างฟังก์ชั่นใหม่สองฟังก์ชั่นบน UserDefaults

เป็นแนวปฏิบัติที่ดีเสมอที่จะไม่เปลี่ยนแปลงข้อมูลแอปพลิเคชันจากเป้าหมายการทดสอบหน่วยดังนั้นเราจึงควรสร้างสถานที่อื่นในการบันทึกข้อมูลผู้ใช้สำหรับเป้าหมายการทดสอบของเรา

ในกรณีนี้เราเริ่มต้นวัตถุใหม่ของ UserDefaults ด้วย suiteName - testDefaults ว่าเป็นอิสระอย่างสมบูรณ์จาก UserDefaults มาตรฐาน

ลองเขียนการทดสอบง่ายๆที่ใช้ UserDefaults

เนื่องจากข้อมูลนี้ใช้สำหรับการทดสอบโดยทั่วไปเท่านั้นเราจึงควรหลีกเลี่ยงการปล่อยให้ข้อมูลนั้นค้างอยู่ในไฟล์แอปพลิเคชันของเราดังนั้นเราจึงสร้างฟังก์ชั่นที่รับผิดชอบในการทิ้งที่เก็บข้อมูลนี้หลังจากเราทำการทดสอบเสร็จแล้ว

สถานที่ที่ดีที่สุดสำหรับการล้างข้อมูลนี้แน่นอนว่าจะเป็นฟังก์ชั่น tearDown ในคลาสทดสอบหน่วยของเรา

วัตถุ Singelton

Singletons Objects มีการใช้งานอย่างสูงบน iOS ในหลาย ๆ API เราสามารถค้นหาได้ใน NSFileManager, NSApplication, UIApplication และในที่อื่น ๆ

การรู้วิธีทดสอบซิงเกิลตันเป็นสิ่งที่มีประโยชน์สำหรับผู้พัฒนาระบบ iOS

ในตัวอย่างของเราเราจะใช้กรอบ iAd ของแอปเปิ้ล เราจะสร้างไฟล์เพื่อรับการตอบสนอง JSON ในท้องถิ่นแทนข้อมูลจริงในการขอรายละเอียดที่มาของโฆษณา

คุณลักษณะที่ดีใน iOS คือส่วนขยายที่รวดเร็วช่วยให้เราไม่เพียง แต่เพิ่มฟังก์ชั่นใหม่สำหรับ API ที่กำหนดไว้ล่วงหน้า แต่ยังทำให้พวกเขาสอดคล้องกับโปรโตคอลที่กำหนดเองของเรา

มานิยามโปรโตคอล AdvertismentClient กันเถอะ

หลังจากนั้นเราปฏิบัติตามโปรโตคอลนี้โดยเริ่มต้นทั้ง ADClient และลูกค้าโฆษณาปลอมของเราดังต่อไปนี้

จากนั้นเราจะเปลี่ยนการพึ่งพาเป็นอย่างใดอย่างหนึ่ง

ส่วนตัว var adClient: AdvertismentClient = ADClient.shared ()

หรือ

ส่วนตัว var adClient: AdvertismentClient = MockAdClient ()

และใช้มันดังต่อไปนี้

ด้วยวิธีนี้เราสามารถตัดสินใจได้อย่างง่ายดายว่าจะใช้ข้อมูลจริงและเมื่อใดการทดสอบขึ้นอยู่กับว่าเราทำการทดสอบหน่วยหรือเรียก API จากเป้าหมายแอปพลิเคชันที่ใช้งานจริงของเรา

ข้อมูลหลัก

ข้อมูลหลักยังคงถูกใช้อย่างมากใน iOS สำหรับการแคชข้อมูล การทดสอบเอนทิตีข้อมูลหลักอาจเป็นเรื่องยุ่งยาก ด้านล่างเราจะอธิบายแนวปฏิบัติที่ดีของการจัดระเบียบบริการข้อมูลหลักและข้อมูลการปลอมแปลง

โดยทั่วไปในกรณีส่วนใหญ่มักจะเป็นสิ่งที่ดีในการสร้างคลาสบริการที่รับผิดชอบในการดึงและเขียนข้อมูลเฉพาะในฐานข้อมูลแทนที่จะใช้รหัสข้อมูลหลักทั่วโครงการ

สิ่งนี้ส่วนใหญ่มีสองประโยชน์:

  • มันจะแยกคุณออกจากฐานข้อมูลพื้นฐานที่กำลังถูกใช้หากคุณต้องการแทนที่ข้อมูลหลักด้วยฐานข้อมูลอื่น ๆ ในอนาคตคุณจะต้องทำการเปลี่ยนแปลงในชั้นเดียวเท่านั้น
  • ด้วยการทำสิ่งนี้เราสามารถตัดสินใจได้อย่างง่ายดายว่า CoreDataStack จะถูกใช้งานหรือการตั้งค่าอื่นใดที่เราอาจต้องการในกรอบอื่น ๆ

เราจะสร้างโปรโตคอล CoreDataStack และหลังจากนั้น CoreDataStacksthat สองตัวที่สอดคล้องกับโปรโตคอลนี้หนึ่ง MainCoreDataStack และหนึ่ง MockCoreDataStack

DatabaseService ของเรานั้นสามารถเริ่มต้นได้โดยวิธีใดวิธีหนึ่งขึ้นอยู่กับว่าเราใช้ในเป้าหมายแอปพลิเคชันของเราหรือตามเป้าหมายการทดสอบหน่วยของเรา

แกนข้อมูลหลักของเราจะมีการตั้งค่าเริ่มต้นดังนี้

เมื่อการทดสอบหน่วยเสมอเราควรหลีกเลี่ยงการเปลี่ยนสถานะของวัตถุ 'ของจริง' ปัจจุบันเมื่อทำการทดสอบ

ดังนั้นเมื่อเราต้องการสร้างเอนทิตีข้อมูลหลักปลอมเราควรมีที่จัดเก็บข้อมูลแบบถาวรแยกต่างหากและใช้การกำหนดค่าประเภทที่เก็บในหน่วยความจำดังนั้นการเปลี่ยนแปลงที่ทำจะไม่ถูกบันทึกไว้ในดิสก์

ตอนนี้เราจะสามารถสร้างบริการฐานข้อมูลของเราที่เริ่มต้นด้วย MainCoreDataStack

และในคลาสทดสอบของเราเราสามารถเริ่มต้นได้ด้วยสแต็กข้อมูลปลอม

ตอนนี้เราสามารถเขียนแบบทดสอบง่ายๆสองสามอย่างดังนี้:

โดยใช้วิธีการนี้เราสามารถทดสอบ DatabaseService ของเราได้อย่างง่ายดายโดยไม่กระทบต่อข้อมูลใด ๆ ที่จัดเก็บโดยเป้าหมายแอปพลิเคชัน

คำขอเครือข่าย

เมื่อทดสอบเลเยอร์เครือข่ายเราสามารถใช้วิธีการที่มุ่งเน้นโปรโตคอลเพื่อสร้างโปรโตคอลและสอดคล้องกับมันโดยทั้งจริง NetworkService และ MockNetworkService และหลังจากนั้นฉีดขึ้นอยู่กับการพึ่งพาโดยใช้บริการจริงหรือเยาะเย้ย

ในบทความนี้แม้ว่าเราจะใช้ไลบรารี่โอเพ่นซอร์สที่ดีมาก ๆ ที่เรียกว่า OHHTTPStubs ที่จะจัดการการเยาะเย้ยและการขัดถูที่ดียิ่งขึ้น

สิ่งที่ดีเกี่ยวกับห้องสมุดนี้คือมันใช้งานได้ดีกับห้องสมุดเครือข่าย iOS ที่มีชื่อเสียง Alamofire

การร้องขอเครือข่าย Stubbing นั้นง่ายมากด้วย OHHTTPStubs คุณสามารถแทนที่การตอบสนองใด ๆ สำหรับพา ธ หรือโฮสต์ที่ระบุได้โดยให้การตอบสนองที่กำหนดเองด้วยพจนานุกรม

หลังจากนี้ทุกคำขอที่เปลี่ยนจากแอปไปยัง URL ต่อไปนี้จะส่งคืนการตอบกลับที่กำหนดเองของเราแทน

ให้ taskURL = URL (สตริง:“ https://jsonplaceholder.typicode.com/todos ")!

สิ่งที่ยอดเยี่ยมเกี่ยวกับการตอบกลับที่กำหนดเองก็คือคุณสามารถทดสอบได้ว่าการจัดการข้อผิดพลาดและกรณีขอบอย่างถูกต้องเพียงแค่ส่งกลับข้อผิดพลาดในการตอบกลับ

การสร้างพจนานุกรมสำหรับการตอบสนองด้วยตนเองนั้นเป็นคุณสมบัติที่ยอดเยี่ยม แต่เมื่อเราต้องการส่งคืนข้อมูล JSON ขนาดใหญ่ที่มีคุณสมบัติจำนวนมากมันอาจกลายเป็นความยุ่งเหยิงและไม่สามารถบำรุงรักษาได้ในชั้นเรียนทดสอบของเรา

ในกรณีเหล่านั้นเราสามารถใช้ไฟล์ JSON เพื่อตอบโต้การตอบสนองต่อไปนี้

ตอนนี้ทุกครั้งที่แอปของเราส่งคำขอเราจะได้รับการตอบกลับจากไฟล์ myResponse.json ที่เราบันทึกไว้ในไฟล์ของเรา

เราควรจำไว้ว่าให้หลีกเลี่ยงการบันทึกข้อมูลที่ละเอียดอ่อนในไฟล์ JSON เหล่านี้เพราะหากเราจัดส่งไฟล์เหล่านี้พร้อมกับแอปพลิเคชันที่สามารถดูได้อย่างง่ายดาย

คุณสามารถตรวจสอบบทความของฉันในหัวข้อความปลอดภัยสำหรับข้อมูลเพิ่มเติม

สรุปแล้ว

การทดสอบหน่วยแอปพลิเคชันของเราเป็นสิ่งจำเป็นหากเราต้องการหลีกเลี่ยงการถดถอยให้มากที่สุดและพยายามจัดหาแอปพลิเคชันที่ไร้ที่ติ

ในบทความนี้เราได้พูดถึงวิธีการทดสอบกรณีทั่วไปที่เกิดขึ้นระหว่างการพัฒนา iOS

เราได้พูดถึงวิธีการทดสอบ UserDefaults, Singeltons, Core Data และ Network Request

หากคุณชอบบทความนี้ให้แน่ใจว่าได้ปรบมือเพื่อแสดงการสนับสนุนของคุณ

ติดตามฉันเพื่อดูบทความอื่น ๆ อีกมากมายที่สามารถยกระดับทักษะนักพัฒนา iOS ของคุณไปอีกระดับ

หากคุณมีคำถามหรือความคิดเห็นโปรดฝากข้อความไว้ที่นี่หรือส่งอีเมลถึงฉันที่ arlindaliu.dev@gmail.com