กรอบการทดสอบระบบอัตโนมัติที่หลากหลายสำหรับ React Native Apps

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

อ่านเพิ่มเติม เกี่ยวกับ Smashing:

• สร้างแอป iOS แรกของคุณด้วย JavaScript
• ทำไมคุณควรพิจารณา React Native สำหรับแอพมือถือของคุณ
• ทดสอบระบบอัตโนมัติสำหรับแอพ เกม และเว็บบนมือถือ
• การแสดงผลฝั่งเซิร์ฟเวอร์ด้วย React, Node และ Express
• 6-6-62. หมายเหตุเกี่ยวกับการเข้าถึงโดยไคลเอนต์

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

มีเทคโนโลยี เครื่องมือ เฟรมเวิร์ก และส่วนประกอบโอเพนซอร์สที่ยอดเยี่ยมมากมายสำหรับการสร้างแอปมือถือแบบเนทีฟ React Native ให้คุณค่าอะไรกับฉาก และเราจะทำให้แน่ใจได้อย่างไรว่าแอปที่สร้างจากแอปจะได้รับการตอบรับอย่างดีจากกลุ่มเป้าหมาย

ในบทความนี้ เราจะมาดูว่ามีอะไรให้ทดสอบแอป React Native บ้าง อันดับแรก ฉันจะอธิบายคุณสมบัติหลักบางประการของ React Native ก่อนดูวิธีใช้งานการทดสอบเหล่านี้ ประการที่สอง ฉันจะจัดประเภทวิธีการทดสอบและกรอบงานในสามระดับ (หน่วย การบูรณาการ การทำงาน) โดยให้ตัวอย่างสำหรับแต่ละระดับ สุดท้ายนี้ ผมจะนำเสนอตัวอย่างง่ายๆ เกี่ยวกับวิธีการใช้การทดสอบโดยใช้เฟรมเวิร์กการทดสอบอัตโนมัติแบบโอเพนซอร์สที่ได้รับความนิยมมากที่สุดสำหรับการทดสอบแอปที่ใช้งานได้

สถาปัตยกรรมพื้นฐานของ React Native Apps

ทั้งหมดนี้เริ่มต้นจาก React เมื่อสามปีที่แล้ว เมื่อ Facebook นำเสนอเฟรมเวิร์กให้กับนักพัฒนาเว็บ มันต้องเป็นที่นิยม ไม่ใช่เพียงเพราะ Facebook เป็นผู้แต่งและพัฒนาโดย แต่เนื่องจากความสามารถที่มอบให้กับนักพัฒนาเว็บ — และโดยเฉพาะอย่างยิ่งวิธีที่มันเปลี่ยนวิธีที่เราสร้างแอพ

แนวคิดของเฟรมเวิร์ก "เรียนรู้ครั้งเดียว เขียนได้ทุกที่" แบบนี้ไม่ใช่เรื่องใหม่ เราเคยเห็นไลบรารี JavaScript ทำสิ่งที่คล้ายกันแล้ว (Sencha, PhoneGap และ Appcelerator เป็นต้น) แต่มีบางอย่างที่ดีกว่าเกี่ยวกับ React ที่มีผลกระทบต่อนิสัยของนักพัฒนา และวิธีที่พวกเขาแบ่ง UI ของแอปพลิเคชันออกเป็นส่วนประกอบที่ไม่ต่อเนื่อง

React Native ไม่ได้ใช้ DOM ในการเรนเดอร์ แต่จะแสดงผลด้วยมุมมอง UI ดั้งเดิม ซึ่งหมายความว่าคุณกำลังใช้ส่วนประกอบดั้งเดิมที่ระบบปฏิบัติการให้มา ขั้นตอนการสร้างผลิตภัณฑ์ประเภทนี้ โดยที่คุณแทนที่ DOM API ด้วย API ที่เปิดเผยมากขึ้น ทำให้นักพัฒนามีระดับนามธรรมที่เหนียวแน่นและเรียบง่ายยิ่งขึ้น

สิ่งสำคัญเกี่ยวกับ React Native คือการนำโมเดลการเขียนโปรแกรม React มาสู่แอพมือถือ การพัฒนาและการทดสอบ มันไม่ได้ทำงานโดยตรงเป็นเครื่องมือหรือเฟรมเวิร์กข้ามแพลตฟอร์ม แต่ช่วยเร่งแนวโน้มการสร้างแอพมือถือบนแพลตฟอร์มใหม่นี้ และนั่นเป็นหนึ่งในรากฐานที่สำคัญของสิ่งที่ทำให้ React Native มีประสิทธิภาพ ง่ายต่อการเรียนรู้ และง่ายต่อการเขียนบนแพลตฟอร์มใหม่นี้

ความแตกต่างที่สำคัญและข้อดีของ Native Mobile กับเว็บก็คือ แทนที่จะเรียกใช้การใช้งาน JavaScript ในเบราว์เซอร์และเปิดเผยองค์ประกอบ HTML เรากำลังพึ่งพา JavaScriptCore ที่ฝังอยู่ในแอป ซึ่งรับเฉพาะแพลตฟอร์ม องค์ประกอบ UI

ทดสอบระบบอัตโนมัติในระดับต่างๆ: หน่วย การบูรณาการ ส่วนประกอบ และการทำงาน

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

ในบทความนี้ ผมจะกล่าวถึงวิธีการทดสอบและกรอบการทำงานอัตโนมัติในสามระดับ จุดสนใจหลักอยู่ที่ระดับสูงสุด การทดสอบการใช้งาน แต่สามารถทดสอบแอป React Native ได้ และการทดสอบสามารถทำแบบอัตโนมัติได้ อย่างน้อยก็ในระดับต่อไปนี้:

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

นอกจาก ReactTestUtils แล้ว React Native ยังมีวิธีการทดสอบหน่วยที่มีประโยชน์ แต่ไม่มีวิธีใดที่ครอบคลุมตรรกะที่แท้จริงของแอปพลิเคชันอย่างละเอียด ดังนั้น แอพมือถือที่สร้างจาก React Native จึงได้รับประโยชน์จากการทดสอบ UI ที่ใช้งานได้มากกว่า มีเฟรมเวิร์กการทดสอบการทำงานอัตโนมัติที่หลากหลาย และเราจะพิจารณาเฟรมเวิร์กที่ได้รับความนิยมสูงสุดบางส่วนในบทความนี้

ในขณะที่การทดสอบหน่วยสามารถทำได้ที่ระดับส่วนประกอบ การทดสอบการทำงานอัตโนมัติจะมีความสามารถที่ดีกว่าสำหรับการทดสอบเอนทิตีที่ใหญ่กว่าในแอป React Native ด้วย React Native การทดสอบส่วนประกอบลอจิกยูนิตสามารถทำได้โดยใช้ไลบรารี JavaScript แบบดั้งเดิมและบังคับให้ React Native ส่งคืนส่วนประกอบปกติแทนที่จะเป็นแบบเนทีฟ ด้วยกรอบการทดสอบการทำงานอัตโนมัติ ส่วนประกอบ UI เป็นส่วนหนึ่งของแอพและง่ายต่อการทดสอบโดยรวม

ฉันจะแยกเฟรมเวิร์กเหล่านี้ออกเป็นเฟรมเวิร์กข้ามแพลตฟอร์มและเฟรมเวิร์กเฉพาะแพลตฟอร์ม ดังที่แสดงในภาพด้านล่าง

ส่วนที่ดีที่สุดของแอป React Native ก็คือแอปเหล่านี้ใช้งานได้จริงสำหรับทั้งแพลตฟอร์มมือถือหลัก (Android และ iOS) ซึ่งหมายความว่าเราได้รับเฟรมเวิร์ก เครื่องมือ และวิธีการดั้งเดิมมากขึ้นสำหรับวัตถุประสงค์ในการทดสอบ เราจะดูกรอบการทดสอบการทำงานอัตโนมัติในส่วนด้านล่างชื่อ “การใช้กรอบการทดสอบการทำงานอัตโนมัติกับ React Native Apps”

มาเริ่มกันที่ความสามารถในการทดสอบหน่วย โดยใช้การทดสอบ JavaScript เพื่อแสดง

การทดสอบหน่วยด้วยความตลกและจัสมิน

ตามค่าเริ่มต้น React Native จะให้การทดสอบ Jest สำหรับการทดสอบหน่วย และวิธีนี้ใช้ได้กับทั้ง Android และ iOS ปัจจุบันความครอบคลุมการทดสอบยังไม่สมบูรณ์แบบ แต่ตาม Facebook จะมีการแนะนำความสามารถในการทดสอบหน่วยเพิ่มเติมใน React Native และผู้ใช้สามารถสร้างของตนเองได้แล้ว

Jest ใช้เฟรมเวิร์กที่ขับเคลื่อนด้วยพฤติกรรมของจัสมินเป็นพื้นฐานสำหรับการทดสอบโค้ด JavaScript ทุกกรณีทดสอบเริ่มต้นจากการเรียกใช้ฟังก์ชัน describe() คล้ายกับวิธีที่ JUnit ใช้คลาส TestCase ฟังก์ชัน description describe() ใช้พารามิเตอร์สองตัว: คำอธิบายและชื่อของกรณีทดสอบ และฟังก์ชันที่จะดำเนินการ ฟังก์ชัน it() ประกอบด้วยขั้นตอนการทดสอบทั้งหมด และ (คล้ายกับ JUnit) มีชุดของฟังก์ชัน expect()

นี่คือตัวอย่างสคริปต์ทดสอบจัสมินสำหรับแอปพลิเคชันผู้เล่น

 describe("Player", function() { var player; var song; beforeEach(function() { player = new Player(); song = new Song(); }); it("should be able to play a song", function() { player.play(song); expect(player.currentlyPlayingSong).toEqual(song); //demonstrates use of custom matcher expect(player).toBePlaying(song); }); describe("when song has been paused", function() { beforeEach(function() { player.play(song); player.pause(); }); it("should indicate the song is paused", function() { expect(player.isPlaying).toBeFalsy(); // demonstrates use of 'not' with a custom matcher expect(player).not.toBePlaying(song); }); it("should be possible to resume", function() { player.resume(); expect(player.isPlaying).toBeTruthy(); expect(player.currentlyPlayingSong).toEqual(song); }); }); // demonstrates use of spies to intercept and test method calls it("tells the current song whether the user has made it a favorite", function() { spyOn(song, 'persistFavoriteStatus'); player.play(song); player.makeFavorite(); expect(song.persistFavoriteStatus).toHaveBeenCalledWith(true); }); //demonstrates use of expected exceptions describe("#resume", function() { it("should throw an exception if song is already playing", function() { player.play(song); expect(function() { player.resume(); }).toThrow("song is already playing"); }); }); });

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

การทดสอบบูรณาการ

ในขณะนี้ การทดสอบการรวมที่เน้นในชุมชน React Native นั้นพร้อมใช้งานสำหรับ iOS เท่านั้น และมีความสามารถในการทดสอบส่วนประกอบอย่างจำกัด การสื่อสารต้องผ่านสะพานและต้องใช้ทั้งส่วนประกอบดั้งเดิมและ JavaScript สำหรับฟังก์ชันการทำงานนี้ มีส่วนประกอบสองส่วนเพื่อใช้การทดสอบการรวมแบบกำหนดเอง RCTestRunner และ RCTestModule

ตัวอย่าง Objective-C พื้นฐานสำหรับการสร้างโครงร่างการทดสอบของแอป iOS จะเริ่มต้นดังนี้:

 @implementation ExampleTests { RCTTestRunner *_runner; } - (void)setUp { [super setUp]; _runner = RCTInitRunnerForApp(@"IntegrationTestHarnessTest", nil); } - void()testExampleTests { [_runner runTest:_cmd module:@"ExampleTests"] } @end

อย่างไรก็ตาม มีวิธีอื่นๆ ในการเรียกใช้การทดสอบการรวมและขยายไปยัง Android และ iOS ทางเลือกที่ดีสำหรับการรันทั้งการทดสอบหน่วยและการรวมคือ Mocha ซึ่งมีเฟรมเวิร์กการทดสอบ JavaScript ที่มีคุณลักษณะหลากหลายซึ่งทำงานบน Node.js Mocha ยังจัดเตรียมการพัฒนาที่ขับเคลื่อนด้วยพฤติกรรม (BDD), การพัฒนาที่ขับเคลื่อนด้วยการทดสอบ (TDD) และอินเทอร์เฟซ QUnit สำหรับการทดสอบ

สำหรับการทดสอบ UI ที่ใช้งานได้ ฉันจะพูดถึงเฟรมเวิร์กการทดสอบอัตโนมัติที่โดดเด่นและใช้กันมากที่สุด รวมถึง Appium, Calabash, XCTest และอื่นๆ อีกสองสามตัว

การใช้เฟรมเวิร์กการทดสอบการทำงานอัตโนมัติด้วย React Native Apps

เพื่อปรับปรุงกระบวนการพัฒนาแอปและเพิ่มความครอบคลุมในการทดสอบสูงสุด เรามีเฟรมเวิร์กการทดสอบอัตโนมัติแบบโอเพนซอร์สมากมายให้เลือก

ตัวเลือกที่ดีที่สุด — หากแอพของคุณทำงานบนแพลตฟอร์มระบบปฏิบัติการหลายตัว — เป็นเฟรมเวิร์กที่รองรับหลายแพลตฟอร์มและเป็นพื้นฐานที่แข็งแกร่งสำหรับการทดสอบอัตโนมัติ ในอุปกรณ์พกพา คำว่า "ข้ามแพลตฟอร์ม" หมายถึงเฟรมเวิร์กที่มี API เครื่องมือและความสามารถเหมือนกันสำหรับทั้ง Android และ iOS

นอกจากนี้ยังมีเฟรมเวิร์กเฉพาะแพลตฟอร์มที่ยอดเยี่ยมอีกด้วย โดยปกติ แต่ละเฟรมเวิร์กได้รับการสร้างขึ้นสำหรับแพลตฟอร์มเฉพาะ และในกรณีส่วนใหญ่ ง่ายต่อการปรับใช้สำหรับแพลตฟอร์มนั้น นอกจาก Appium และ Calabash แล้ว ฉันจะพูดถึงเฟรมเวิร์กเฉพาะแพลตฟอร์มสี่เฟรมในบทความนี้: Robotium และ Espresso สำหรับ Android และ XCTest และ EarlGrey สำหรับ iOS

เมื่อพูดถึงการทดสอบระบบอัตโนมัติ โปรดจำไว้ว่าแอพที่สร้างด้วย React Native นั้นใช้งานได้ทั้งบน iOS และ Android; ดังนั้นกรอบการทดสอบการทำงานอัตโนมัติจะทำงานได้ดีกับพวกเขา

ตัวอย่างที่ฉันใช้กับแต่ละเฟรมเวิร์กคือการใช้งาน UI ปุ่มตัวเลือกพื้นฐาน

 <Radio onSelect={this.onSelect.bind(this)} defaultSelect={this.state.optionSelected - 1}> <Option color="black" selectedColor="#000000"> <Item title="First option" description="First radio button"/> </Option> <Option color="black" selectedColor="#000000"> <Item title="Second option" description="Second radio button"/> </Option> <Option color="black" selectedColor="#000000"> <Item title="Third option" description="Third radio button"/> </Option> </Radio>

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

กรอบงานข้ามแพลตฟอร์ม

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

Appium

Appium เป็นเฟรมเวิร์กการทดสอบอัตโนมัติแบบโอเพนซอร์ส พร้อมเครื่องมือตรวจสอบที่ทำงานได้ดีสำหรับแอปเนทีฟ ไฮบริด และเว็บบนมือถือ ใช้ JSONWireProtocol ภายในเพื่อโต้ตอบกับแอป iOS และ Android โดยใช้ Selenium WebDriver ด้วยเหตุนี้ Appium จึงทำงานได้ดีมากสำหรับเว็บบนมือถือเช่นกัน และกรณีการใช้งานจะคล้ายกันมากหากใช้ Selenium สำหรับการทดสอบเว็บ

อันที่จริง Appium เป็นดาวรุ่งในการทดสอบระบบอัตโนมัติบนอุปกรณ์เคลื่อนที่ในปีที่ผ่านมา เดิมทีมันถูกสร้างขึ้นเพื่อให้รองรับข้ามแพลตฟอร์มสำหรับทั้งแพลตฟอร์มหลัก Android และ iOS

การเป็นข้ามแพลตฟอร์มหมายความว่าเฟรมเวิร์กและสคริปต์ทำงานเหมือนกันทุกประการบนทั้งสองแพลตฟอร์ม นอกจากนี้ Appium ยังให้การสนับสนุนภาษาการเขียนโปรแกรมที่ยอดเยี่ยม — นักพัฒนาสามารถเขียนการทดสอบโดยใช้ภาษาที่พวกเขาชื่นชอบ (เช่น Java, Ruby, Python, C#) เครื่องมือและสภาพแวดล้อม นอกจากนี้ยังง่ายต่อการเริ่มต้น สร้างและบำรุงรักษาการทดสอบที่ใช้ซ้ำได้ และดำเนินการทดสอบเหล่านั้นบนอุปกรณ์จริง

เมื่อพูดถึงแอปที่ขับเคลื่อนโดย React Native ไม่จำเป็นต้องใช้ JavaScript การทดสอบสามารถเขียนในภาษาใดก็ได้ ตัวอย่างเช่น สคริปต์ Appium สามารถมีลักษณะดังนี้:

 driver.findElement(By.id("com.example.app:id/radio0")).click(); driver.findElement(By.id("com.example.app:id/radio1")).click(); driver.findElement(By.id("com.example.app:id/radio2")).click(); driver.findElement(By.id("com.example.app:id/editText1")).click(); driver.findElement(By.id("com.example.app:id/editText1")).sendKeys("Simple Test"); driver.findElement(By.name("Answer")).click(); // or alternatively like this: driver.findElement(By.id("com.example.app:id/button1")).click();

ฟังก์ชัน WebDriver เหล่านี้เข้าถึงแอปที่ทำงานบนอุปกรณ์ได้อย่างไร โดยทั่วไป Appium จะเริ่มสคริปต์ทดสอบบนอุปกรณ์หรือโปรแกรมจำลอง ซึ่งจะสร้างเซิร์ฟเวอร์และรับฟังคำสั่งจากเซิร์ฟเวอร์ Appium หลัก เหมือนกับเซิร์ฟเวอร์ Selenium ซึ่งรับคำขอ HTTP จากไลบรารีไคลเอนต์ Selenium ความแตกต่างระหว่าง Android และ iOS แสดงไว้ในภาพด้านล่าง:

ด้วย iOS Selenium WebDriver รับคำสั่งจากสคริปต์ Appium (เช่น click() ) และส่งในรูปแบบของ JSON ผ่านคำขอ HTTP ไปยังเซิร์ฟเวอร์ Appium Appium รู้บริบทของระบบอัตโนมัติและส่งคำสั่งนี้ไปยังเซิร์ฟเวอร์คำสั่งของ Instruments ซึ่งรอให้ไคลเอ็นต์คำสั่ง Instruments หยิบขึ้นมาและดำเนินการด้วย bootstrap.js ในสภาพแวดล้อม iOS Instruments เมื่อดำเนินการคำสั่งแล้ว ไคลเอ็นต์คำสั่งของ Instruments จะส่งข้อความกลับไปที่เซิร์ฟเวอร์ Appium ซึ่งจะบันทึกทุกอย่างที่เกี่ยวข้องกับคำสั่งในคอนโซล รอบนี้ดำเนินต่อไปจนกว่าสคริปต์ทดสอบจะเสร็จสิ้น

บน Android สิ่งต่างๆ ทำงานในลักษณะเดียวกัน ยกเว้นว่าเฟรมเวิร์กที่ใช้คือ Selendroid และ UiAutomator กล่าวโดยย่อ Appium แปลคำสั่ง WebDriver เป็นคำสั่ง UiAutomator (API ระดับ 17 หรือสูงกว่า) หรือคำสั่ง Selendroid (API ระดับ 16 หรือต่ำกว่า) บนอุปกรณ์จริง bootstrap.jar เรียกใช้เซิร์ฟเวอร์ TCP ที่ได้รับคำสั่งจากไคลเอนต์ TCP กระบวนการนี้คล้ายกันบน iOS

หากคุณสนใจที่จะเริ่มต้นใช้งาน Appium มีสื่อการสอนมากมาย รวมถึงคำแนะนำทีละขั้นตอนและบทช่วยสอนเกี่ยวกับ Appium

น้ำเต้า

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

เมื่อเปรียบเทียบกับ Appium แล้ว Calabash ให้วิธีที่ง่ายกว่าในการสร้างการทดสอบข้ามแพลตฟอร์มสำหรับ Android และ iOS นี่เป็นเพราะคำศัพท์ตรงไปตรงมาและภาษาที่เน้นข้อกำหนด ซึ่งทำให้การทดสอบ Calabash เหมือนกันบนทั้งสองแพลตฟอร์ม การทดสอบจริงเขียนด้วย Gherkin และเรียกใช้ใน Cucumber

เนื่องจากความสามารถเหล่านี้ ความแตกต่างระหว่าง Calabash ที่ทำงานบน Android และบนแอปพลิเคชัน iOS นั้นมีเพียงเล็กน้อย อีกครั้ง ไม่มีนัยยะสำหรับแอป React Native เนื่องจากส่วนประกอบและส่วนต่อประสานผู้ใช้ทั้งหมดนั้นมาจากแพลตฟอร์มเหล่านี้อย่างสมบูรณ์

อย่างไรก็ตาม การทดสอบพื้นฐานและขั้นตอนการสร้างการทดสอบยังคงเหมือนเดิม การทดสอบ Calabash (และ Gherkin) ประกอบด้วยคุณลักษณะ สถานการณ์จำลอง และขั้นตอนต่างๆ แนวทางที่แนะนำคือการกรอกรายละเอียดระดับสูงสุดก่อน: คุณลักษณะ ตามด้วยสถานการณ์ และขั้นตอนจริง หลักการที่ดีคือการสร้างคุณลักษณะของ Calabash ก่อน

ตัวอย่างด้านล่างแสดงให้เห็นว่าแอปพลิเคชันของเราและส่วนประกอบ UI (ปุ่มตัวเลือก ฟิลด์ข้อความ และปุ่ม) จะถูกนำไปใช้ใน Calabash อย่างไร:

 Feature: Answer the question feature Scenario: As a valid user, I want to answer app question, I wait for text "What is the best way to test application on a hundred devices?" Then I press radio button 0 Then I press radio button 1 Then I press radio button 2 Then I enter text "Simple Test" into field with id "editText1" Then I press view with id "Button1"

ขั้นตอนมักจะเริ่มต้นด้วยหนึ่งในคำหลักที่ given then when and หรือ but อย่างไรก็ตาม พวกเขาไม่จำเป็นต้อง; สามารถใช้ * แทนได้

นอกจากนี้ Calabash ยังใช้กันอย่างแพร่หลายโดยผู้ที่ไม่ใช่นักพัฒนา และสามารถใช้สำหรับข้อมูลจำเพาะของผลิตภัณฑ์และเอกสารประกอบเนื่องจากภาษาและตรรกะที่เข้าใจง่าย ในที่สุด ฟีเจอร์และสถานการณ์ต่างๆ จะถูกรวมไว้ในโค้ด Ruby

การตั้งค่า Calabash และเริ่มทำงานเป็นเรื่องง่าย หากคุณติดตั้ง Bundler และ Ruby (หรือ rbenv) ไว้ เพียงกดสองสามบรรทัดเหล่านี้ในคอนโซลของคุณ จากนั้นระบบจะตั้งค่าสภาพแวดล้อม Calabash:

 $ gem install calabash-android $ gem install calabash-cucumber

การดำเนินการนี้จะดูแลการติดตั้ง Calabash-Android และ Calabash-iOS และการเดินทางของคุณด้วยการทดสอบอัตโนมัติสามารถเริ่มต้นได้

กรอบงานเฉพาะแพลตฟอร์ม

เมื่อพูดถึงการทดสอบอัตโนมัติบนแอพ Android และ iOS มีข้อดีบางประการในการใช้เฟรมเวิร์กเฉพาะแพลตฟอร์มมากกว่าเฟรมเวิร์กข้ามแพลตฟอร์ม ตัวอย่างเช่น เฟรมเวิร์กบางตัวสร้างขึ้นอย่างใกล้ชิดกับ SDK และ IDE ซึ่งพร้อมใช้งานในขณะที่แอปพลิเคชันอยู่ระหว่างการพัฒนา มาดูตัวอย่างเฟรมเวิร์กประเภทนี้สำหรับ Android และ iOS กัน

Robotium และ ExtSolo (แอนดรอยด์)

Robotium เป็นหนึ่งในเฟรมเวิร์กการทดสอบแรกๆ สำหรับแอป Android แบบเนทีฟและแบบไฮบริด การทดสอบ UI ที่สร้างด้วย Robotium ช่วยให้สามารถทดสอบการทำงาน ระบบ และการยอมรับของผู้ใช้สำหรับแอป Android ที่ครอบคลุมและจัดการกิจกรรม Android หลายรายการ อันที่จริง Robotium ให้การสนับสนุนสำหรับ Android เวอร์ชันแรกๆ โดยเริ่มจาก API ระดับ 8

เมื่อเร็วๆ นี้ Robotium ได้รับการขยายด้วยไลบรารี ExtSolo ซึ่งมีคุณสมบัติที่มีประโยชน์มากมายสำหรับการทดสอบแอป:

• ปรับขนาดอัตโนมัติของการคลิก x และ y สำหรับความละเอียดในการแสดงผลใดๆ
• การลากหลายเส้นทาง
• จับภาพหน้าจออัตโนมัติในขณะที่การทดสอบล้มเหลว
• สถานที่จำลอง (พิกัด GPS);
• การเปลี่ยนภาษาของอุปกรณ์ Android
• ควบคุมการเชื่อมต่อ Wi-Fi;

ด้วยโค้ด Java การทดสอบทำได้ง่ายโดยใช้ Java SDK และ IDE ฟังก์ชันหลักที่ใช้ในตัวอย่างนี้คือ findViewById ซึ่งค้นหามุมมองที่ระบุโดยแอตทริบิวต์ id องค์ประกอบ UI สามารถระบุได้ด้วยชื่อ คลาส หรือแอตทริบิวต์อื่นๆ ตัวอย่างโค้ดของเราที่มีแอตทริบิวต์ id จะมีลักษณะดังนี้:

 solo.clickOnView(solo.findViewById("com.example.app:id/radio0")); solo.clickOnView(solo.findViewById("com.example.app:id/radio1")); solo.clickOnView(solo.findViewById("com.example.app:id/radio2")); solo.enterText((EditText) solo.findViewById("com.example.app:id/editText1"), "Simple Test"); solo.clickOnView(solo.findViewById("com.example.app:id/button1"));

Robotium ที่นี่พยายามค้นหาองค์ประกอบ UI ตาม id คำอธิบาย และคุณลักษณะอื่นๆ ขออภัย นี่ไม่ใช่แนวทางที่ดีที่สุดเสมอไป และอาจไม่ได้ผลดีกับส่วนประกอบ webview อย่างไรก็ตาม ด้วยความช่วยเหลือของไลบรารี ExtSolo ผู้ใช้สามารถกำหนดคลิกและการโต้ตอบอื่นๆ บนองค์ประกอบ UI ที่ปรับขนาดตามความละเอียดได้ นอกจากนี้ยังสามารถใช้พิกัดฮาร์ดโค้ดได้และมาตราส่วนเหล่านี้เมื่อความละเอียดในการแสดงผลเปลี่ยนไป

หากคุณกำลังใช้ Robotium การเริ่มต้นใช้งาน Robotium ExtSolo นั้นง่ายและไม่ยุ่งยาก เพียงโคลนที่เก็บสำหรับตัวคุณเองและสร้างไลบรารี:

 $ git clone https://github.com/bitbar/robotium-extensions $ ant clean instrument

หลังจากนี้ ให้วางไฟล์ .jar ที่เพิ่งสร้างไว้ในโฟลเดอร์ libs ในโปรเจ็กต์ Android Studio ของคุณ และตรวจดูให้แน่ใจว่าโปรเจ็กต์ของคุณเชื่อมโยงกับไฟล์นั้น ฟีเจอร์และบริการเพิ่มเติมที่ยอดเยี่ยมทั้งหมดนี้อยู่ในพื้นที่ทำงานของคุณแล้ว

เอสเพรสโซ่ (แอนดรอยด์)

กรอบงานการทดสอบ Espresso มี API สำหรับการเขียนการทดสอบ UI เพื่อจำลองการโต้ตอบของผู้ใช้สำหรับแอป Android Espresso API มีน้ำหนักเบาและมีองค์ประกอบหลักสามอย่าง: viewMatchers , viewActions และ viewAssertions

ความงามของ Espresso คือการซิงโครไนซ์วิธีทดสอบและองค์ประกอบ UI ที่กำลังทดสอบโดยอัตโนมัติ ตัวอย่างเช่น หากสคริปต์ทดสอบต้องการกดปุ่ม แต่ปุ่มยังไม่ปรากฏบนหน้าจอ จะรอจนกว่าจะสามารถกดปุ่มนี้ได้ (เช่น มองเห็นได้และเกิดการคลิกได้) สิ่งนี้ทำให้การดำเนินการทดสอบเร็วมากเพราะไม่มีสคริปต์ทดสอบที่จำเป็นต้องมีคำสั่งพักเครื่องหรือรอ นอกจากนี้ นักพัฒนาไม่ต้องการตรรกะเพิ่มเติมเพื่อจัดการกับปัญหาที่เกี่ยวข้องกับเวลา

 // R class ID identifier for radio buttons onView(withId(R.id.radio0)).perform(click()); onView(withId(R.id.radio1)).perform(click()); onView(withId(R.id.radio2)).perform(click()); onView(withId(R.id.EditText1)).perform(click()); // Instead of R, we use getIdentifier onView(withId(getInstrumentation().getTargetContext().getResources() .getIdentifier("com.example.app:id/EditText1", null, null))).perform((typeText("Simple Test"))); onView(withId(getInstrumentation().getTargetContext().getResources() .getIdentifier("com.example.app:id/Button1", null, null))).perform(click());

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

ที่ Google IO 2016 Google ได้แนะนำ Espresso Test Recorder เป็นส่วนสำคัญของ Android Studio แม้ว่าคุณลักษณะนี้จะยังไม่พร้อมใช้งาน แต่จะคุ้มค่ากับการรอคอยอย่างแน่นอน

XCTest และ KIF (iOS)

XCTest เชื่อมต่อกับ Xcode อย่างแน่นหนา แต่ยังคงใช้งานได้กับทั้งอุปกรณ์ iOS จริงและเครื่องจำลอง XCTest ช่วยให้นักพัฒนาสามารถเขียนการทดสอบสำหรับส่วนประกอบในทุกระดับ และยังมีกรอบงานสำหรับความสามารถในการทดสอบ UI การทดสอบ XCTest ถูกจัดกลุ่มเป็นคลาสย่อยของ XCTestCase การเขียนการทดสอบด้วย XCTest ควรเป็นเรื่องเล็กน้อยสำหรับนักพัฒนา iOS เนื่องจาก XCTest เข้ากันได้อย่างสมบูรณ์กับทั้ง Objective-C และ Swift

KIF (ย่อมาจาก “keep it functional”) คือเฟรมเวิร์กการทดสอบการรวม iOS ที่เกี่ยวข้องอย่างใกล้ชิดและใช้เป้าหมายการทดสอบ XCTest การทดสอบ KIF สามารถดำเนินการได้โดยตรงใน XCTestCase หรือคลาสย่อยใดๆ KIF ช่วยให้แอปพลิเคชัน iOS ทำงานอัตโนมัติได้โดยง่ายโดยใช้ประโยชน์จากคุณลักษณะการช่วยสำหรับการเข้าถึงที่ระบบปฏิบัติการทำให้ผู้ที่มีความบกพร่องทางการมองเห็นสามารถใช้งานได้

มาดูกันว่าองค์ประกอบ UI ของเราจะมีลักษณะอย่างไรกับ Objective-C:

 - (void)testClicksOnRadioButtons { [tester tapViewWithAccessibilityLabel:@”Radio1”]; [tester tapViewWithAccessibilityLabel:@”Radio2”]; [tester tapViewWithAccessibilityLabel:@”Radio3”]; [tester enterText:@”Simple Test” intoViewWithAccessibilityLabel:@”editText1”]; [tester tapViewWithAccessibilityLabel:@”Answer”]; }

อีกทางหนึ่งกับ Swift การทดสอบจะดูเรียบง่ายดังนี้:

 testClicksOnRadioButtons() { let app = XCUIApplication() app.radiobutton[0].tap() app.radiobutton[1].tap() app.radiobutton[2].tap() app.staticTexts[“Simple Test”] app.button[0].tap() }

โปรดทราบว่ารหัสเทียมระดับสูงนี้ต้องการรหัสเพิ่มเติมเพื่อให้ทำงานได้อย่างสมบูรณ์ หากคุณกำลังมองหาข้อมูลเพิ่มเติมเกี่ยวกับ XCTest และโดยทั่วไปเกี่ยวกับการใช้ความสามารถในการทดสอบ Xcode คุณได้ครอบคลุมถึง Apple

เอิร์ลเกรย์ (iOS)

เมื่อต้นปีที่ผ่านมา Google ได้เปิดตัวเฟรมเวิร์กการทดสอบแอป iOS ที่ใช้งานได้ซึ่งมีชื่อว่า EarlGrey การใช้ภายในโดย Google มันทำงานได้ดีกับแอพ iOS ดั้งเดิมเช่น YouTube, Google ปฏิทิน, Google Photos, Google Play Music เป็นต้น และได้จุดประกายความสนใจอย่างจริงจัง ในการเริ่มต้นใช้งาน EarlGrey คุณจะต้องติดตั้งสภาพแวดล้อม Xcode และมีความรู้พื้นฐานเกี่ยวกับการพัฒนา iOS

มีความคล้ายคลึงกันมากระหว่าง EarlGrey และ Espresso (ใช่ ทั้งสองได้รับการพัฒนาโดย Google) และคุณลักษณะเหล่านี้ทำให้กรอบงานทั้งสองทำงานและดำเนินการทดสอบได้อย่างรวดเร็ว เช่นเดียวกับเอสเพรสโซ่ EarlGrey จะทำการทดสอบโดยอัตโนมัติเพื่อรอกิจกรรม (แอนิเมชั่น คำขอเครือข่าย ฯลฯ) ก่อนที่จะพยายามโต้ตอบกับ UI ทำให้การทดสอบการเขียนง่ายขึ้น เนื่องจากนักพัฒนาไม่จำเป็นต้องกังวลเกี่ยวกับคำสั่งพักเครื่องหรือรอ นอกจากนี้ ตัวโค้ดเองยังง่ายต่อการบำรุงรักษา เนื่องจากมีคำอธิบายขั้นตอนของขั้นตอนการทดสอบ

EarlGrey ยังมีตัวจับคู่ที่มีให้จากคลาส GREYMatchers เอกสารแนะนำการใช้องค์ประกอบ UI กับพารามิเตอร์การช่วยสำหรับการเข้าถึง ในการระบุองค์ประกอบ UI นักพัฒนาสามารถใช้ grey_accessibilityID() หรือ grey_accessibilityLabel()

 - (void)testBasicSelectionAndAction { [[EarlGrey selectElementWithMatcher::grey_accessibilityID(@"ClickHere")] performAction:grey_tap()]; // Example of long press with EarlGrey matchers - (void)testLongPress { [[EarlGrey selectElementWithMatcher::grey_accessibilityLabel(@"Box")] performAction:grey_longPressWithDuration(0.5f)]; [[EarlGrey selectElementWithMatcher::grey_accessibilityLabel(@"One Long Press")] assertWithMatcher:grey_sufficientlyVisible()]; // Example of multi-select, visible click on items - (void)testCollectionMatchers { id visibleSendButtonMatcher = grey_allOf(grey_accessibilityID(@"Box"), grey_sufficientlyVisible(), nil); [[EarlGrey selectElementWithMatcher:visibleSendButtonMatcher] performAction:grey_tap()]; }

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

บทสรุป

เราได้ครอบคลุมพื้นฐานของแอปพลิเคชัน React Native และวิธีการทดสอบโดยใช้วิธีการและเฟรมเวิร์กต่างๆ สิ่งนี้เกิดขึ้นค่อนข้างบ่อย แต่มาตรฐานอุตสาหกรรมสำหรับการทดสอบมือถืออัตโนมัติที่ระดับ UI ที่ใช้งานได้ จะทำงานบนแอป React Native เหมือนกับที่ทำกับแอปพื้นฐานอื่นๆ เฟรมเวิร์กการทดสอบอัตโนมัติที่เราได้กล่าวถึงในที่นี้มีการใช้กันอย่างแพร่หลายสำหรับแอปบนอุปกรณ์เคลื่อนที่ที่มาพร้อมเครื่อง แอปไฮบริด เว็บบนอุปกรณ์เคลื่อนที่ ตลอดจนแอป React Native

โดยสรุป การกำหนดภาษาการเขียนโปรแกรมที่สร้างแอปพลิเคชันบนมือถือนั้นไม่สำคัญ เนื่องจากจะไม่มีผลใดๆ ต่อเฟรมเวิร์กการทดสอบอัตโนมัติที่สามารถทดสอบได้ ดังที่ได้กล่าวไปแล้ว เฟรมเวิร์กการทดสอบอัตโนมัติที่ทรงพลังมากมายพร้อมให้ใช้งานแล้วในปัจจุบัน ซึ่งแอป React Native จะใช้งานได้เมื่อรวมเป็น APK หรือ IPA

คุณใช้อะไรในการทดสอบแอป React Native ชั่งน้ำหนักด้วยความคิดเห็นด้านล่าง!