สับสนเล็กน้อยเกี่ยวกับความแตกต่างของกรอบงานจำลองเช่น NMock เทียบกับ VS 2011 Fakes Framework เมื่อผ่าน MSDN สิ่งที่ฉันเข้าใจคือ Fakes ช่วยให้คุณสามารถเยาะเย้ยการอ้างอิงของคุณได้เช่นเดียวกับ RhinoMock หรือ NMock อย่างไรก็ตามวิธีการนั้นแตกต่างกัน Fakes สร้างรหัสเพื่อให้บรรลุฟังก์ชันนี้ แต่ Mocks framework ไม่ได้ ความเข้าใจของฉันถูกต้องหรือไม่? Fakes เป็นเพียงกรอบการจำลองอื่น
คำตอบ:
คำถามของคุณเกี่ยวกับว่าเฟรมเวิร์ก MS Fakes แตกต่างจาก NMock อย่างไรและดูเหมือนว่าคำตอบอื่น ๆ ได้แก้ไขบางส่วนแล้ว แต่นี่คือข้อมูลเพิ่มเติมเกี่ยวกับวิธีการที่เหมือนกันและแตกต่างกันอย่างไร NMock ก็คล้ายกับ RhinoMocks และ Moq ดังนั้นฉันจึงจัดกลุ่มพวกมันด้วย NMock
มีความแตกต่างที่สำคัญ 3 ประการที่ฉันเห็นระหว่าง NMock / RhinoMocks / Moq และ MS Fakes Framework:
เฟรมเวิร์กปลอมของ MS ใช้โค้ดที่สร้างขึ้นเช่นเดียวกับ Accessors ใน Visual Studio เวอร์ชันก่อนหน้าแทนที่จะเป็นประเภททั่วไป เมื่อคุณต้องการใช้เฟรมเวิร์กปลอมสำหรับการอ้างอิงคุณเพิ่มแอสเซมบลีที่มีการอ้างอิงกับการอ้างอิงของโปรเจ็กต์ทดสอบจากนั้นคลิกขวาที่มันเพื่อสร้างการทดสอบเป็นสองเท่า (สตับหรือชิม) จากนั้นเมื่อคุณทำการทดสอบคุณจะใช้คลาสที่สร้างขึ้นเหล่านี้แทน NMock ใช้ generics เพื่อบรรลุสิ่งเดียวกัน (เช่นIStudentRepository studentRepository = mocks.NewMock<IStudentRepository>()) ในความคิดของฉันแนวทางกรอบ MS Fakes ยับยั้งการนำทางโค้ดและการปรับโครงสร้างใหม่จากภายในการทดสอบเนื่องจากคุณกำลังทำงานกับคลาสที่สร้างขึ้นไม่ใช่อินเทอร์เฟซจริง
นางสาวปลอมสมบูรณ์วัสดุกรอบและไฝ (shims) ในขณะที่ NMock, RhinoMocks และ Moq ทั้งหมดให้สมบูรณ์และmocks ฉันไม่เข้าใจการตัดสินใจของ MS ที่จะไม่รวมการล้อเลียนและฉันเองก็ไม่ได้เป็นแฟนตัวยงด้วยเหตุผลที่อธิบายไว้ด้านล่าง
ด้วยกรอบงานปลอมของ MS คุณสามารถจัดหาวิธีการอื่นที่คุณต้องการใช้ในการตัดทอน ภายในการใช้งานทางเลือกเหล่านี้คุณสามารถระบุค่าที่ส่งคืนและติดตามข้อมูลเกี่ยวกับวิธีการหรือวิธีการเรียกใช้เมธอด ด้วย NMock, RhinoMocks และ Moq คุณจะสร้างวัตถุจำลองจากนั้นใช้วัตถุนั้นเพื่อระบุค่าการส่งคืนที่ถูกตรึงหรือเพื่อติดตามการโต้ตอบ (วิธีการเรียกใช้และวิธีการ) ฉันพบว่าวิธีการปลอมของ MS ซับซ้อนกว่าและแสดงออกน้อยกว่า
เพื่อชี้แจงความแตกต่างในสิ่งที่กรอบการทำงานมีให้: NMock, RhinoMocks และ Moq ล้วนมีการทดสอบสองประเภท (ต้นขั้วและม็อก) เฟรมเวิร์กของปลอมมีต้นขั้วและโมล (พวกเขาเรียกมันว่า shims) และน่าเสียดายที่ไม่มีการล้อเลียน เพื่อให้เข้าใจถึงความแตกต่างและความคล้ายคลึงกันระหว่าง NMock และ MS Fakes การทำความเข้าใจประเภทการทดสอบที่แตกต่างกันเหล่านี้คืออะไร:
Stubs: Stubs ใช้เมื่อคุณต้องการระบุค่าสำหรับวิธีการหรือคุณสมบัติที่จะถูกถามถึงการทดสอบของคุณเป็นสองเท่าโดยวิธีการภายใต้การทดสอบ ตัวอย่างเช่นเมื่อวิธีการของฉันภายใต้การทดสอบเรียกใช้เมธอด DoesStudentExist () ของการทดสอบ IStudentRepository สองครั้งฉันต้องการให้มันคืนค่าจริง
ความคิดของต้นขั้วใน NMock และ MS ปลอมเหมือนกัน แต่ด้วย NMock คุณจะทำสิ่งนี้:
Stub.On(mockStudentRepository).Method("DoesStudentExist").Will(Return.Value(true));
และด้วย MSFakes คุณจะทำสิ่งนี้:
IStudentRepository studentRepository = new DataAccess.Fakes.StubIStudentRepository() // Generated by Fakes.
{
DoesStudentExistInt32 = (studentId) => { return new Student(); }
};
ข้อสังเกตในตัวอย่าง MS Fakes คุณสร้างการใช้งานใหม่ทั้งหมดสำหรับเมธอด DoesStudentExist (โปรดสังเกตว่ามันถูกเรียกว่า DoesStudentExistInt32 เนื่องจากกรอบงานปลอมจะผนวกชนิดข้อมูลพารามิเตอร์เข้ากับชื่อเมธอดเมื่อสร้างวัตถุต้นขั้วฉันคิดว่าสิ่งนี้บดบังความชัดเจนของ การทดสอบ) ความจริงแล้วการใช้งาน NMock ยังทำให้ฉันมีข้อบกพร่องเพราะใช้สตริงเพื่อระบุชื่อวิธีการ (ยกโทษให้ฉันถ้าฉันเข้าใจผิดว่าตั้งใจจะใช้ NMock อย่างไร) วิธีนี้ยับยั้งการปรับโครงสร้างใหม่ได้จริง ๆ และฉันขอแนะนำ RhinoMocks หรือ Moq มากกว่า NMock ด้วยเหตุผลนี้
Mocks: Mocks ใช้เพื่อตรวจสอบการโต้ตอบระหว่างวิธีการของคุณภายใต้การทดสอบและการอ้างอิง ด้วย NMock คุณทำได้โดยตั้งความคาดหวังไว้ในลักษณะนี้:
Expect.Once.On(mockStudentRepository).Method("Find").With(123);
นี่เป็นอีกเหตุผลหนึ่งที่ฉันชอบ RhinoMocks และ Moq มากกว่า NMock NMock ใช้รูปแบบการคาดหวังที่เก่ากว่าในขณะที่ RhinoMocks และ Moq ทั้งคู่สนับสนุนวิธีการจัดเรียง / กระทำ / ยืนยันซึ่งคุณระบุการโต้ตอบที่คาดว่าจะเป็นการยืนยันเมื่อสิ้นสุดการทดสอบเช่นนี้ :
stubStudentRepository.AssertWasCalled( x => x.Find(123));
โปรดทราบอีกครั้งว่า RhinoMocks ใช้แลมด้าแทนสตริงเพื่อระบุวิธีการ เฟรมเวิร์กปลอมของ ms ไม่ได้มีการล้อเลียนเลย ซึ่งหมายความว่าในการใช้งานที่ไม่มีการตัดทอน (ดูคำอธิบายของต้นขั้วด้านบน) คุณต้องตั้งค่าตัวแปรที่คุณตรวจสอบในภายหลังว่าตั้งค่าถูกต้อง จะมีลักษณะดังนี้:
bool wasFindCalled = false;
IStudentRepository studentRepository = new DataAccess.Fakes.StubIStudentRepository()
{
DoesStudentExistInt32 = (studentId) =>
{
wasFindCalled = true;
return new Student();
}
};
classUnderTest.MethodUnderTest();
Assert.IsTrue(wasFindCalled);
ฉันพบว่าวิธีนี้มีความซับซ้อนเล็กน้อยเนื่องจากคุณต้องติดตามการโทรในต้นขั้วแล้วยืนยันในภายหลังในการทดสอบ ฉันพบว่า NMock และโดยเฉพาะ RhinoMocks เป็นตัวอย่างที่แสดงออกได้ชัดเจนมากขึ้น
ไฝ (ชิม):พูดตรงๆฉันไม่ชอบโมลเพราะมีโอกาสใช้ผิดประเภท สิ่งหนึ่งที่ฉันชอบมากเกี่ยวกับการทดสอบหน่วย (และโดยเฉพาะอย่างยิ่ง TDD) คือการทดสอบโค้ดของคุณช่วยให้คุณเข้าใจว่าคุณเขียนโค้ดที่ไม่ดีตรงไหน เนื่องจากการทดสอบโค้ดที่เขียนไม่ดีนั้นทำได้ยาก สิ่งนี้ไม่เป็นความจริงเมื่อใช้โมลเนื่องจากไฝได้รับการออกแบบมาเพื่อให้คุณทดสอบกับการพึ่งพาที่ไม่ได้ฉีดหรือเพื่อทดสอบวิธีการส่วนตัว มันทำงานคล้ายกับต้นขั้วยกเว้นว่าคุณใช้ ShimsContext ดังนี้:
using (ShimsContext.Create())
{
System.Fakes.ShimDateTime.NowGet = () => { return new DateTime(fixedYear, 1, 1); };
}
ความกังวลของฉันกับ shims คือผู้คนจะเริ่มมองว่าพวกเขาเป็น "วิธีที่ง่ายกว่าในการทดสอบหน่วย" เพราะไม่ได้บังคับให้คุณเขียนโค้ดอย่างที่ควรจะเป็น สำหรับบทความที่สมบูรณ์ยิ่งขึ้นเกี่ยวกับแนวคิดนี้โปรดดูโพสต์ของฉัน:
สำหรับข้อมูลเพิ่มเติมเกี่ยวกับข้อกังวลบางประการที่เกี่ยวข้องกับเฟรมเวิร์กปลอมโปรดดูที่โพสต์เหล่านี้:
หากคุณสนใจที่จะเรียนรู้ RhinoMocks นี่คือวิดีโอฝึกอบรม Pluralsight (การเปิดเผยแบบเต็ม - ฉันเขียนหลักสูตรนี้และได้รับค่าลิขสิทธิ์สำหรับการดู แต่ฉันคิดว่ามันใช้ได้กับการสนทนานี้ดังนั้นฉันจึงรวมไว้ที่นี่):
คุณถูกต้อง แต่ยังมีเรื่องราวอีกมากมาย สิ่งที่สำคัญที่สุดที่ต้องหลีกเลี่ยงจากคำตอบนี้คือ:
สถาปัตยกรรมของคุณควรใช้ต้นขั้วและการฉีดขึ้นรูปอย่างเหมาะสมแทนที่จะใช้ไม้ค้ำยันของปลอมและล้อเลียน
ของปลอมและล้อเลียนมีประโยชน์สำหรับการทดสอบโค้ดที่คุณไม่ควรหรือไม่สามารถเปลี่ยนแปลงได้เช่น:
Shims (รู้จักกันในชื่อ "Moles" ในระหว่างการพัฒนา) เป็นกรอบการเยาะเย้ยที่ดำเนินการโดยการโทรอ้อม แทนที่จะสร้างการเยาะเย้ยอย่างระมัดระวัง (ใช่แม้การใช้ Moq ก็ค่อนข้างเจ็บปวด!) ชิมเพียงแค่ใช้วัตถุรหัสการผลิตที่มีอยู่แล้ว Shims เพียงกำหนดเส้นทางการโทรใหม่จากเป้าหมายการผลิตไปยังผู้ร่วมทดสอบ
Stubsถูกสร้างขึ้นจากอินเทอร์เฟซในโครงการเป้าหมาย วัตถุ Stub นั้นเป็นเพียงการใช้งานอินเทอร์เฟซ ประโยชน์ของการใช้ Stub type คือคุณสามารถสร้าง Stub ได้อย่างรวดเร็วโดยไม่ทำให้โครงการทดสอบของคุณยุ่งเหยิงด้วย Stubs แบบใช้ครั้งเดียวจำนวนมากไม่ต้องพูดถึงการเสียเวลาในการสร้าง แน่นอนว่าคุณควรสร้างต้นขั้วคอนกรีตเพื่อใช้ในการทดสอบหลาย ๆ ครั้ง
การใช้ Fakes อย่างมีประสิทธิภาพ (ประเภท Shims, Mocks และ Stub) ใช้เวลาทำความคุ้นเคยเล็กน้อย แต่ก็คุ้มค่ากับความพยายาม ฉันประหยัดเวลาในการพัฒนาเป็นการส่วนตัวได้หลายสัปดาห์ผ่านการใช้ประเภท Shims / Mole, Mocks และ Stub ฉันหวังว่าคุณจะสนุกกับเทคโนโลยีเท่าที่ฉันมี!
ตามที่ฉันเข้าใจทีม Visual Studio ต้องการหลีกเลี่ยงการแข่งขันกับไลบรารีจำลองต่างๆที่มีให้สำหรับ. NET MS มักเผชิญกับการตัดสินใจที่ยากลำบากเช่นนี้ พวกเขาจะได้รับความเสียหายหากพวกเขาไม่ได้จัดเตรียมฟังก์ชันการทำงานบางอย่างไว้ ("ทำไม MS ไม่จัดให้มีไลบรารีจำลองให้เราการล้อเลียนเป็นข้อกำหนดทั่วไปหรือไม่") และจะถูกสาปแช่งหากพวกเขาทำ ("เหตุใด Microsoft จึงดำเนินการอย่างก้าวร้าวและผลักดัน ผู้สนับสนุนธรรมชาติออกจากตลาด? ") บ่อยครั้งมาก แต่ก็ไม่เสมอไปพวกเขาตัดสินใจที่จะหยุดเพียงแค่จัดหาทางเลือกให้กับเทคโนโลยีที่มีอยู่และได้รับการตอบรับเป็นอย่างดี ดูเหมือนว่าจะเป็นเช่นนั้นที่นี่
คุณสมบัติ shim ของ Fakes นั้นมีประโยชน์จริงๆ แน่นอนว่ามีอันตราย ต้องใช้วินัยบางอย่างเพื่อให้แน่ใจว่าคุณใช้สิ่งนี้เมื่อจำเป็นเท่านั้น อย่างไรก็ตามมันเติมช่องว่างขนาดใหญ่ ข้อร้องเรียนหลักของฉันคือมันถูกส่งมาพร้อมกับรุ่น Ultimate ของ VS 2012 เท่านั้นดังนั้นจึงมีให้เฉพาะส่วนย่อยของชุมชนการพัฒนา. ช่างน่าเสียดาย
ของปลอมรวมถึงวัตถุ "ของปลอม" สองประเภท อย่างแรกเรียกว่า "ต้นขั้ว" โดยพื้นฐานแล้วเป็นหุ่นจำลองที่สร้างขึ้นโดยอัตโนมัติซึ่งพฤติกรรมเริ่มต้นสามารถ (และโดยปกติจะ) ถูกลบล้างเพื่อให้เป็นการล้อเลียนที่น่าสนใจ อย่างไรก็ตามมันขาดคุณสมบัติบางอย่างที่ส่วนใหญ่ของกรอบการจำลองที่มีอยู่ในปัจจุบันเสนอให้ ตัวอย่างเช่นหากคุณต้องการตรวจสอบว่ามีการเรียกใช้เมธอดบนอินสแตนซ์ต้นขั้วคุณจะต้องเพิ่มตรรกะนี้ด้วยตัวเอง โดยพื้นฐานแล้วหากคุณกำลังเขียนล้อเลียนของคุณเองในตอนนี้ต้นขั้วอาจดูเหมือนได้รับการปรับปรุง อย่างไรก็ตามหากคุณใช้เฟรมเวิร์กการเยาะเย้ยที่มีคุณสมบัติครบถ้วนอยู่แล้วคุณอาจรู้สึกว่ามีชิ้นส่วนสำคัญบางอย่างที่ขาดหายไปจาก Fakes Stub
ประเภทอื่น ๆ ของวัตถุที่นำเสนอโดย Fakes เรียกว่า "shim" แสดงให้เห็นกลไกในการแทนที่พฤติกรรมของการอ้างอิงที่ไม่ได้ (หรือไม่สามารถ) แยกออกได้อย่างเพียงพอสำหรับการเปลี่ยนมาตรฐานผ่านการล้อเลียน AFAIK, TypeMock เป็นเพียงหนึ่งในกรอบการจำลองที่สำคัญที่นำเสนอฟังก์ชันประเภทนี้
BTW หากคุณเคยทดลองใช้ Moles มาก่อน Fakes ก็เป็นสิ่งเดียวกันในที่สุดก็ออกจาก Microsoft Research และไปสู่ผลิตภัณฑ์จริง
เกี่ยวกับวัตถุปลอม (Shim + Stub) มีการกำหนดไว้อย่างดีข้างต้นแม้ว่าฉันจะเดาว่าย่อหน้าสุดท้ายในความคิดเห็นสุดท้ายสรุปสถานการณ์ทั้งหมดได้ค่อนข้างดี
แม้ว่าหลายคนจะโต้แย้งว่าวัตถุปลอม (Shim + Stub) เป็นทรัพย์สินที่ดีที่จะมีในบางกรณีการทดสอบหน่วย แต่ข้อเสียคือไม่ว่าคุณจะใช้ Visual Studio 2012 หรือ Visual Studio 2013 ตัวเลือกเหล่านี้จะมีให้ใช้งานเท่านั้น กับรุ่น Premium หรือ Ultimate IOW หมายความว่าคุณจะไม่เรียกใช้ Fakes (Shim + Stub) ใด ๆ ในรุ่น Pro ใด ๆ
คุณอาจเห็นตัวเลือกเมนู Fakes (Shim + Stub) ในเวอร์ชัน Pro แต่ระวังมีโอกาสค่อนข้างสูงที่คุณจะจบลงโดยไม่มีอะไรเลย ... มันจะไม่สร้างข้อผิดพลาดในการรวบรวมใด ๆ ที่บอกคุณว่ามีบางอย่างที่สำคัญ หายไปไม่มีตัวเลือกดังนั้นอย่าเสียเวลา ...
เป็นปัจจัยสำคัญที่ต้องพิจารณาในทีม dev โดยเฉพาะอย่างยิ่งหากมีคนเดียวที่ใช้เวอร์ชัน Ultimate ในขณะที่ทุกคนใช้เวอร์ชัน Pro ... ในทางกลับกัน Moq สามารถติดตั้งได้อย่างง่ายดายผ่าน Nuget ไม่ว่าคุณจะใช้ Visual Studio เวอร์ชันใดก็ตาม ฉันไม่มีปัญหาในการใช้ Moq กุญแจสำคัญของเครื่องมือใด ๆ คือการรู้ว่าพวกเขาใช้เพื่ออะไรและใช้อย่างไรอย่างถูกต้อง;)