การทดสอบ iOS / รายละเอียด TDD / BDD และการทดสอบการรวมและการยอมรับ


229

เทคโนโลยีที่ดีที่สุดที่ใช้ในการพัฒนาพฤติกรรมที่ขับเคลื่อนบน iPhone คืออะไร? และโครงการตัวอย่างโอเพ่นซอร์สบางโครงการที่แสดงให้เห็นถึงการใช้เสียงของเทคโนโลยีเหล่านี้คืออะไร นี่คือตัวเลือกที่ฉันพบ:


การทดสอบหน่วย

ทดสอบ ::สไตล์หน่วย

  1. OCUnit / SenTestingKitที่อธิบายไว้ในคู่มือการพัฒนา iOS: การประยุกต์ใช้งานหน่วยทดสอบและอื่น ๆ ที่อ้างอิง OCUnit
  2. จับ
  3. GHUnit
  4. Google Toolbox สำหรับ Mac: การทดสอบหน่วย iPhone

สไตล์RSpec

  1. กีวี่ (ซึ่งมาพร้อมกับการเยาะเย้ย & ความคาดหวัง)
  2. ต้นซีดาร์
  3. จัสมินกับUI Automationดังแสดงในข้อกำหนดการทดสอบการยอมรับ iOS ที่คล่องแคล่ว

การทดสอบการยอมรับ

สไตล์ซีลีเนียม

  1. UI Automation (ทำงานบนอุปกรณ์)

    ปรับปรุง: กรอบบวบดูเหมือนว่าจะผสมผสานแตงกวาและ UI อัตโนมัติ! :)

    โพสต์บล็อกเก่า:

  2. UISpecกับUISpecRunner

  3. FoneMonkey

สไตล์แตงกวา

  1. FrankและiCuke (ตามแตงกวาตรงกับ iPhone talk )

    • แฟรงก์กลุ่ม Googleมีกิจกรรมอื่น ๆ อีกมากมายกว่ากลุ่ม Google iCuke
    • Frank ทำงานบนทั้งอุปกรณ์และเครื่องจำลองในขณะที่ iCuke ทำงานในเครื่องจำลองเท่านั้น
    • แฟรงก์ดูเหมือนว่าจะมีชุดที่ครอบคลุมมากขึ้นของคำนิยามขั้นตอนกว่าiCuke คำจำกัดความของขั้นตอน และแฟรงก์ยังมีบทสรุปความหมายขั้นตอนเกี่ยวกับวิกิพีเดียของพวกเขา
    • ฉันเสนอให้เรารวม iCuke & Frank (คล้ายกับที่ Merb & Rails ผสาน) เนื่องจากพวกเขามีเป้าหมายร่วมกันคือ Cucumber สำหรับ iOS
  2. KIF (ใช้งานได้)โดยSquare

  3. Zucchini Frameworkใช้ไวยากรณ์ของแตงกวาสำหรับการเขียนการทดสอบและใช้ CoffeeScript สำหรับคำจำกัดความขั้นตอน

เพิ่ม

ข้อสรุป

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

สำหรับการทดสอบหน่วยฉันเคยใช้OCUnit / SenTestingKitใน XCode 4 มันง่ายและแข็ง แต่ฉันชอบภาษา BDD มากกว่า TDD ( ทำไม RSpec ถึงดีกว่า Test :: Unit ?) เพราะคำพูดของเราสร้างโลกของเรา ดังนั้นตอนนี้ผมใช้กีวีกับ ARC & Kiwi จบรหัส ฉันชอบกีวีมากกว่า Cedar เพราะมันสร้างจากด้านบนของ OCUnit และมาพร้อมกับนักจับคู่สไตล์ RSpec & mocks / stubs UPDATE: ตอนนี้ผมมองเข้าไปใน OCMock เพราะปัจจุบันกีวีไม่สนับสนุน stubbing วัตถุโทรฟรีสะพาน

สำหรับการทดสอบการยอมรับฉันใช้ UI Automation เพราะมันยอดเยี่ยม มันช่วยให้คุณบันทึกแต่ละกรณีทดสอบทำให้การทดสอบการเขียนโดยอัตโนมัติ นอกจากนี้ Apple ยังพัฒนาและมีอนาคตที่สดใส นอกจากนี้ยังใช้งานได้บนอุปกรณ์และจากเครื่องมือซึ่งช่วยให้คุณสมบัติเจ๋ง ๆ อื่น ๆ เช่นการแสดงการรั่วไหลของหน่วยความจำ น่าเสียดายที่ด้วย UI อัตโนมัติฉันไม่รู้วิธีเรียกใช้รหัส Objective-C แต่ด้วย Frank & iCuke คุณสามารถทำได้ ดังนั้นฉันจะทดสอบวัตถุ Objective-C ระดับต่ำกว่าด้วยการทดสอบหน่วยหรือสร้างUIButtonเฉพาะสำหรับการTESTกำหนดค่าการสร้างซึ่งเมื่อคลิกจะเรียกใช้รหัส Objective-C

คุณใช้โซลูชันใด

คำถามที่เกี่ยวข้อง


1
ฉันรู้ว่าอย่างน้อยไม่กี่เดือนที่ผ่านมาว่าห้องทดลองการพิจาณาใช้ต้นซีดาร์ (อืมฉันเดาว่าเห็นได้ชัดว่ามันอยู่ในบัญชี Github ของพวกเขา) ด้วยการสนับสนุนจากร้านค้าเช่นนั้นฉันจะต้องเป็นตัวเลือก
Jed Schneider

1
นั่นเป็นจุดที่ดี แต่แล้วอีกครั้ง Apple จะแนะนำให้ใช้กรอบการทดสอบหน่วยของพวกเขาไม่ใช่ Cedar ไม่ใช่หรือ? ดังนั้นมันคือหัวใจสำคัญ แอปเปิ้ล. จะไปที่ไหนด้วย?
ma11hew28

2
ฉันเขียนบทความเปรียบเทียบ Frank, KIF และ UIAutomation ที่อาจเป็นที่สนใจของผู้อ่านหัวข้อนี้sgleadow.github.com/blog/2011/10/26/…
Stew

คำตอบ:


53

TL; DR

ที่ Pivotal เราเขียน Cedar เพราะเราใช้และรัก Rspec ในโครงการ Ruby ของเรา Cedar ไม่ได้หมายถึงการแทนที่หรือแข่งขันกับ OCUnit มันหมายถึงการนำความเป็นไปได้ของการทดสอบแบบ BDD มาสู่ Objective C เช่นเดียวกับ Rspec ซึ่งเป็นผู้บุกเบิกการทดสอบแบบ BDD ใน Ruby แต่ยังไม่ได้ตัด Test :: Unit การเลือกอย่างใดอย่างหนึ่งเป็นเรื่องของการกำหนดลักษณะ

ในบางกรณีเราออกแบบ Cedar เพื่อเอาชนะข้อบกพร่องบางอย่างในวิธีที่ OCUnit ทำงานให้เรา โดยเฉพาะเราต้องการให้สามารถใช้ดีบักเกอร์ในการทดสอบเพื่อรันการทดสอบจากบรรทัดคำสั่งและในการสร้าง CI และรับเอาต์พุตข้อความที่เป็นประโยชน์ของผลการทดสอบ สิ่งเหล่านี้อาจเป็นประโยชน์กับคุณไม่มากก็น้อย

คำตอบที่ยาว

การตัดสินใจระหว่างสองเฟรมเวิร์กการทดสอบเช่น Cedar และ OCUnit (ตัวอย่าง) มีสองสิ่ง: สไตล์ที่ต้องการและใช้งานง่าย ฉันจะเริ่มต้นด้วยสไตล์เพราะมันเป็นเพียงความเห็นและความชอบ ใช้งานง่ายมีแนวโน้มที่จะเป็นชุดของการแลกเปลี่ยน

การพิจารณารูปแบบที่ดีกว่าเทคโนโลยีหรือภาษาที่คุณใช้ x การทดสอบยูนิตแบบยูนิทนั้นใช้เวลานานกว่าการทดสอบสไตล์ BDD แต่ทว่าหลังนั้นได้รับความนิยมอย่างรวดเร็วเนื่องจาก Rspec

ข้อได้เปรียบหลักของการทดสอบแบบ xUnit คือความเรียบง่ายและการยอมรับอย่างกว้างขวาง (ในหมู่นักพัฒนาที่เขียนการทดสอบหน่วย) เกือบทุกภาษาที่คุณสามารถเขียนโค้ดได้มีกรอบ xUnit สไตล์พร้อมใช้งาน

เฟรมเวิร์กสไตล์ BDD มีแนวโน้มที่จะมีความแตกต่างที่สำคัญสองประการเมื่อเปรียบเทียบกับ xUnit-style: วิธีที่คุณจัดโครงสร้างการทดสอบ (หรือข้อกำหนด) และไวยากรณ์สำหรับการเขียนการยืนยันของคุณ สำหรับฉันความแตกต่างทางโครงสร้างเป็นความแตกต่างหลัก x การทดสอบหน่วยเป็นมิติเดียวด้วยวิธี setUp หนึ่งวิธีสำหรับการทดสอบทั้งหมดในคลาสทดสอบที่กำหนด อย่างไรก็ตามคลาสที่เราทดสอบไม่ใช่มิติเดียว เรามักจะต้องทดสอบการกระทำในบริบทที่แตกต่างกันที่อาจขัดแย้งกัน ตัวอย่างเช่นพิจารณาคลาส ShoppingCart อย่างง่ายพร้อมเมธอด addItem: (สำหรับจุดประสงค์ของคำตอบนี้ฉันจะใช้ Objective C ไวยากรณ์) พฤติกรรมของวิธีนี้อาจแตกต่างกันเมื่อรถเข็นว่างเปล่าเมื่อเทียบกับเมื่อรถเข็นมีรายการอื่น ๆ ; อาจแตกต่างกันหากผู้ใช้ป้อนรหัสส่วนลด มันอาจแตกต่างกันหากรายการที่ระบุสามารถ ' t ถูกส่งโดยวิธีการจัดส่งที่เลือก; ฯลฯ เนื่องจากเงื่อนไขที่เป็นไปได้เหล่านี้ตัดกันซึ่งกันและกันคุณจะพบกับบริบทที่เป็นไปได้ที่เพิ่มขึ้นในเชิงเรขาคณิต ในการทดสอบแบบ xUnit ซึ่งมักจะนำไปสู่วิธีการมากมายที่มีชื่อเช่น testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodApplies โครงสร้างของกรอบงานสไตล์ BDD ช่วยให้คุณสามารถจัดระเบียบเงื่อนไขเหล่านี้เป็นรายบุคคลซึ่งฉันพบว่าทำให้ง่ายขึ้นเพื่อให้แน่ใจว่าฉันครอบคลุมทุกกรณีรวมทั้งง่ายต่อการค้นหาเปลี่ยนแปลงหรือเพิ่มเงื่อนไขแต่ละรายการ ตัวอย่างเช่นการใช้ไวยากรณ์ของ Cedar วิธีการด้านบนจะเป็นดังนี้: ในการทดสอบแบบ xUnit ซึ่งมักจะนำไปสู่วิธีการมากมายที่มีชื่อเช่น testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodApplies โครงสร้างของกรอบงานสไตล์ BDD ช่วยให้คุณสามารถจัดระเบียบเงื่อนไขเหล่านี้เป็นรายบุคคลซึ่งฉันพบว่าทำให้ง่ายขึ้นเพื่อให้แน่ใจว่าฉันครอบคลุมทุกกรณีรวมทั้งง่ายต่อการค้นหาเปลี่ยนแปลงหรือเพิ่มเงื่อนไขแต่ละรายการ ตัวอย่างเช่นการใช้ไวยากรณ์ของ Cedar วิธีการด้านบนจะเป็นดังนี้: ในการทดสอบแบบ xUnit ซึ่งมักจะนำไปสู่วิธีการมากมายที่มีชื่อเช่น testAddItemWhenCartIsEmptyAndNoDiscountCodeAndShippingMethodApplies โครงสร้างของกรอบงานสไตล์ BDD ช่วยให้คุณสามารถจัดระเบียบเงื่อนไขเหล่านี้เป็นรายบุคคลซึ่งฉันพบว่าทำให้ง่ายขึ้นเพื่อให้แน่ใจว่าฉันครอบคลุมทุกกรณีรวมทั้งง่ายต่อการค้นหาเปลี่ยนแปลงหรือเพิ่มเงื่อนไขแต่ละรายการ ตัวอย่างเช่นการใช้ไวยากรณ์ของ Cedar วิธีการด้านบนจะเป็นดังนี้:

describe(@"ShoppingCart", ^{
    describe(@"addItem:", ^{
        describe(@"when the cart is empty", ^{
            describe(@"with no discount code", ^{
                describe(@"when the shipping method applies to the item", ^{
                    it(@"should add the item to the cart", ^{
                        ...
                    });

                    it(@"should add the full price of the item to the overall price", ^{
                        ...
                    });
                });

                describe(@"when the shipping method does not apply to the item", ^{
                    ...
                });
            });

            describe(@"with a discount code", ^{
                ...
            });
        });

        describe(@"when the cart contains other items, ^{
            ...
        });
    });
});

ในบางกรณีคุณจะพบบริบทที่มีชุดการยืนยันที่เหมือนกันซึ่งคุณสามารถ DRY โดยใช้บริบทตัวอย่างที่แชร์

ความแตกต่างหลักที่สองระหว่างเฟรมเวิร์กสไตล์ BDD และเฟรมเวิร์กสไตล์ xUnit การยืนยัน (หรือ "matcher") ไวยากรณ์ทำให้รูปแบบของสเป็คค่อนข้างดีกว่า บางคนชอบมันจริง ๆ บางคนก็ไม่ชอบ

ที่นำไปสู่คำถามของการใช้งานง่าย ในกรณีนี้แต่ละเฟรมเวิร์กมีข้อดีและข้อเสีย:

  • OCUnit นั้นมีความยาวมากกว่า Cedar และถูกรวมเข้ากับ Xcode โดยตรง ซึ่งหมายความว่าการสร้างเป้าหมายการทดสอบใหม่นั้นเป็นเรื่องง่ายและส่วนใหญ่แล้วจะทำการทดสอบและใช้งาน "ใช้งานได้" ในทางกลับกันเราพบว่าในบางกรณีเช่นการใช้งานบนอุปกรณ์ iOS การได้รับการทดสอบจาก OCUnit นั้นเป็นไปไม่ได้ การตั้งค่าสเปคของ Cedar นั้นใช้งานได้มากกว่าการทดสอบ OCUnit เนื่องจากคุณได้รับไลบรารี่และเชื่อมโยงกับมันด้วยตัวคุณเอง (ไม่เคยมีเรื่องเล็กน้อยใน Xcode) เรากำลังพยายามทำให้การตั้งค่าง่ายขึ้นและคำแนะนำใด ๆ ก็ยินดีต้อนรับ

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

    • เราต้องการที่จะใช้ดีบักเกอร์ คุณเรียกใช้ specs ของ Cedar เหมือนกับที่คุณเรียกใช้โปรแกรมอื่น ๆ ดังนั้นคุณสามารถใช้ดีบักเกอร์ได้ในลักษณะเดียวกัน
    • เราต้องการการบันทึกคอนโซลอย่างง่ายในการทดสอบ คุณสามารถใช้ NSLog () ในการทดสอบ OCUnit ได้ แต่เอาต์พุตจะเข้าสู่หน้าต่างบิลด์ที่คุณต้องเปิดขั้นตอนบิลด์เพื่อที่จะอ่าน
    • เราต้องการให้ง่ายต่อการอ่านรายงานการทดสอบทั้งในบรรทัดคำสั่งและใน Xcode ผลลัพธ์ของ OCUnit ปรากฏอย่างชัดเจนในหน้าต่างการสร้างใน Xcode แต่การสร้างจากบรรทัดคำสั่ง (หรือเป็นส่วนหนึ่งของกระบวนการ CI) ส่งผลให้ผลลัพธ์การทดสอบสอดแทรกด้วยเอาต์พุตบิลด์อื่น ๆ มากมาย ด้วยขั้นตอนการ build และ run แยกกัน Cedar จะแยกเอาท์พุทออกมาดังนั้นผลลัพธ์การทดสอบจึงหาง่าย ค่าเริ่มต้นของนักทดสอบซีดาร์คัดลอกสไตล์การพิมพ์มาตรฐาน "" สำหรับแต่ละสเป็คที่ผ่าน "F" สำหรับสเปคที่ล้มเหลวเป็นต้น Cedar ยังมีความสามารถในการใช้ออบเจ็กต์นักข่าวที่กำหนดเองดังนั้นคุณสามารถให้ผลลัพธ์ออกมาได้ตามที่คุณต้องการด้วยความพยายามเล็กน้อย
  • OCUnit เป็นกรอบการทดสอบหน่วยอย่างเป็นทางการสำหรับ Objective C และได้รับการสนับสนุนจาก Apple แอปเปิ้ลมีทรัพยากรที่ไร้ขีด จำกัด โดยทั่วไปดังนั้นหากพวกเขาต้องการบางสิ่งบางอย่างมันก็จะเสร็จ และท้ายที่สุดนี่คือ sandbox ของ Apple ที่เราเล่นอยู่อย่างไรก็ตามด้านพลิกของเหรียญนั้นคือ Apple ได้รับตามคำขอสนับสนุนมูลค่าหลายพันล้านครั้งและรายงานข้อผิดพลาดในแต่ละวัน พวกเขาดีมากเกี่ยวกับการจัดการพวกเขาทั้งหมด แต่พวกเขาอาจไม่สามารถจัดการกับปัญหาที่คุณรายงานได้ทันทีหรือเลย Cedar ใหม่กว่าและอบน้อยกว่า OCUnit มาก แต่ถ้าคุณมีคำถามหรือปัญหาหรือคำแนะนำส่งข้อความไปยังรายชื่อผู้รับจดหมายของ Cedar (cedar-discuss@googlegroups.com) และเราจะทำสิ่งที่เราสามารถช่วยคุณได้ นอกจากนี้โปรดแยกรหัสจาก Github (github.com/pivotal/cedar) และเพิ่มสิ่งที่คุณคิดว่าหายไป

  • การเรียกใช้การทดสอบ OCUnit บนอุปกรณ์ iOS อาจเป็นเรื่องยาก จริงๆแล้วฉันไม่ได้ลองมาซักพักนึงแล้วมันอาจจะง่ายขึ้น แต่ครั้งสุดท้ายที่ฉันลองฉันก็ไม่สามารถทดสอบ OCUnit สำหรับการทำงานของ UIKit ใด ๆ เมื่อเราเขียน Cedar เรามั่นใจว่าเราสามารถทดสอบโค้ดที่ขึ้นกับ UIKit ได้ทั้งบนโปรแกรมจำลองและบนอุปกรณ์

สุดท้ายเราเขียน Cedar สำหรับการทดสอบหน่วยซึ่งหมายความว่ามันไม่สามารถเทียบเคียงได้กับโครงการอย่าง UISpec เป็นเวลานานแล้วที่ฉันลองใช้ UISpec แต่ฉันเข้าใจว่ามันจะเน้นไปที่การขับ UI บนอุปกรณ์ iOS เป็นหลัก เราตัดสินใจเป็นพิเศษว่าจะไม่พยายามให้ Cedar รองรับคุณสมบัติเหล่านี้เนื่องจาก Apple กำลังจะประกาศ UIAutomation (ในเวลานั้น)


ขอบคุณสำหรับการตอบสนองอย่างละเอียด ฉันจะอ่านหนังสือ RSpec และลอง Ceder ฉันย้าย UISpec ไปที่ส่วนซีลีเนียมและเพิ่ม UIAutomation ที่นั่นด้วย ฉันกำลังอ่านโพสต์บล็อกของคุณเกี่ยวกับ UIAutomation แฟรงค์ดูเรียบง่ายขึ้นและอ่านได้มากขึ้นรวมถึงเอกสารที่ดีกว่าดังนั้นฉันจึงคิดว่าจะเริ่มด้วย ฉันแค่หวังว่ามันจะทรงพลังเท่ากับ UIAutomation คุณบอกว่า UIAutomation สามารถทดสอบปัญหาวงจรชีวิตได้ ฉันสงสัยว่า iCuke ก็สามารถทำได้เช่นกัน ...
ma11hew28

8

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


5

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


ขอบคุณ ฉันเห็นอันนั้น แต่ลืมพูดถึงมัน
ma11hew28

ตอนที่ 1 สำหรับ GHUnit ใช้มันมากกับ OCMock มันง่ายที่จะติดตั้งขยายและใช้งานได้อย่างน่าเชื่อถือ
drekka

4

รายการที่ยอดเยี่ยม!

ฉันพบโซลูชันที่น่าสนใจอีกวิธีหนึ่งสำหรับการทดสอบ UI ของแอปพลิเคชัน iOS

กรอบบวบ

UIAutomationมันขึ้นอยู่กับ เฟรมเวิร์กช่วยให้คุณสามารถเขียนสถานการณ์เป็นศูนย์กลางของหน้าจอในแตงกวาอย่างมีสไตล์ สถานการณ์สามารถดำเนินการได้ในเครื่องมือจำลองและบนอุปกรณ์จากคอนโซล (เป็น CI ที่เป็นมิตร)

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

แต่ละหน้าจอจะต้องมีการอธิบายCoffeScriptและเครื่องมือที่มันเขียนด้วยตนเองในทับทิม มันเป็นฝันร้ายของโพลีกลอต แต่เครื่องมือนี้ให้นามธรรมที่ดีUIAutomationและเมื่อมีการอธิบายหน้าจอมันสามารถจัดการได้แม้กับคน QA


แน่น! ขอบคุณ ฉันเพิ่มไปยังคำถามข้างต้น
ma11hew28

2

ฉันจะเลือก iCuke สำหรับการทดสอบการยอมรับและ Cedar สำหรับการทดสอบหน่วย UIAutomation เป็นขั้นตอนในทิศทางที่ถูกต้องสำหรับ Apple แต่เครื่องมือต้องการการสนับสนุนที่ดีกว่าสำหรับการรวมอย่างต่อเนื่อง การเรียกใช้การทดสอบ UIAutomation โดยอัตโนมัติโดยใช้เครื่องมือไม่สามารถทำได้ในขณะนี้


1

GHUnit ดีสำหรับการทดสอบหน่วย สำหรับการทดสอบการรวมฉันใช้ UISpec กับความสำเร็จ (github fork ที่นี่: https://github.com/drync/UISpec ) แต่ฉันรอคอยที่จะลองใช้ iCuke เนื่องจากสัญญาจะติดตั้งที่เบาและคุณสามารถ ใช้รางทดสอบความดีเช่น RSpec และแตงกวา


1

ขณะนี้ฉันใช้spectaสำหรับ rspec เช่นการตั้งค่าและเป็นพันธมิตร (ดังที่ได้กล่าวไว้แล้ว) expectaซึ่งมีตัวเลือกการจับคู่ที่ยอดเยี่ยมมากมาย


0

ฉันชอบ OCDSpec2 จริงๆ แต่ฉันลำเอียงฉันเขียน OCDSpec และมีส่วนร่วมในครั้งที่สอง

มันเร็วมากแม้ใน iOS ส่วนหนึ่งเป็นเพราะมันถูกสร้างขึ้นมาจากพื้นดินแทนที่จะวางไว้บน OCUnit มันมีไวยากรณ์ RSpec / Jasmine เช่นกัน

https://github.com/ericmeyer/ocdspec2

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.