เหตุใดจึงต้องทดสอบการดู MVC

23

ขณะนี้ฉันกำลังตั้งค่าพื้นฐานสำหรับแอปพลิเคชัน ASP.Net MVC และฉันกำลังมองหาการทดสอบหน่วยที่ฉันควรเตรียมที่จะเขียน ฉันเคยเห็นในหลาย ๆ ที่ที่ผู้คนพูดว่า 'ไม่ต้องกังวลกับการทดสอบมุมมองของคุณไม่มีตรรกะและมันไม่สำคัญ

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

สถานการณ์ตัวอย่าง: สมมติ ว่าเรากำลังติดต่อกับแอพ CRUD มาตรฐานกับเอนทิตีลูกค้า ลูกค้ามีชื่อและที่อยู่ ในการทดสอบแต่ละระดับฉันต้องการตรวจสอบว่าตรรกะการดึงข้อมูลลูกค้าได้รับทั้งชื่อและที่อยู่อย่างถูกต้อง

เพื่อทดสอบหน่วยเก็บข้อมูลฉันเขียนการทดสอบการรวมระบบเพื่อตีฐานข้อมูล ในการทดสอบกฎธุรกิจฉันจำลองที่เก็บข้อมูลป้อนข้อมูลกฎธุรกิจที่เหมาะสมและตรวจสอบผลลัพธ์ที่คาดหวังของฉันคืน

สิ่งที่ฉันต้องการทำ: ในการทดสอบ UI หน่วยฉันจำลองกฎธุรกิจตั้งค่าอินสแตนซ์ลูกค้าที่คาดหวังของฉันแสดงผลมุมมองและตรวจสอบว่ามุมมองมีค่าที่เหมาะสมสำหรับอินสแตนซ์ที่ฉันระบุ

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

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

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

ฉันรู้สึกว่าฉันไม่เข้าใจแนวคิดหลักบางอย่าง บางคนสามารถอธิบายได้หรือไม่ว่าทำไมการตอบรับการทดสอบในทันทีเกี่ยวกับความถูกต้องของมุมมอง MVC เป็นสิ่งที่ไม่ดี (หรือถ้าไม่เลวก็ไม่ใช่วิธีที่คาดหวังในการรับฟังความคิดเห็น)

unit-testing asp.net-mvc

— Peter Bernier
แหล่งที่มา

1

"To unit-test the repository, I write an integration test"รออะไร? นั่นไม่ใช่การทดสอบหน่วยของที่เก็บ คุณกำลังทำการทดสอบโดยอัตโนมัติ แต่โค้ดที่อยู่ภายใต้การทดสอบยังรวมถึง DAL และฐานข้อมูล ในการทดสอบหน่วยเก็บข้อมูลคุณต้องแยกมันเหมือนกับกฎทางธุรกิจของคุณ

— StuperUser

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

— Raynos

2

@ Raynos ด้วยความเคารพฉันจะต้องไม่เห็นด้วย หากฉัน (หรือผู้พัฒนารายอื่น) วางสาย UI อย่างไม่เหมาะสมเพื่อแสดงผลแอตทริบิวต์ข้อมูลหนึ่งในฟิลด์ UI สำหรับอีกรายการหนึ่ง (ตัวอย่างเช่น 'ชื่อจริง' ใน 'ชื่อนามสกุล' ซึ่งไม่มีส่วนเกี่ยวข้องกับเครื่องมือสร้างเทมเพลตหรือ มันเป็นปัญหา DAL หรือ BR .. มันเป็นปัญหาที่เห็นได้ชัดในมุมมองเท่านั้น

— Peter Bernier

1

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

— Raynos

9

การทดสอบ UI อย่างง่ายนั้นง่ายพอใน ASP.NET MVC สิ่งสำคัญที่คุณต้องทำคือยืนยันว่า HTML ที่ส่งคืนมีองค์ประกอบที่คุณต้องการ แม้ว่าสิ่งนี้จะช่วยให้มั่นใจว่าหน้า HTML มีโครงสร้างตามที่คุณคาดหวัง แต่ก็ไม่ได้ทดสอบ UI อย่างสมบูรณ์

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

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

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

— Berin Loritsch
แหล่งที่มา

1

"สิ่งสำคัญที่คุณต้องทำคือยืนยันว่า HTML ที่ส่งคืนมีองค์ประกอบที่คุณต้องการ" นี่คือสิ่งที่ฉันพยายามจะทำและมันก็กลายเป็นเรื่องไม่สำคัญ คุณสามารถชี้ไปที่ลิงก์ที่ใช้งานการกระทำของคอนโทรลเลอร์ที่เฉพาะเจาะจงได้หรือไม่? (ฉันเคยทำงานกับการเขียนสองสามครั้ง แต่ RenderPartial ไม่ประสบความสำเร็จในสิ่งที่ฉันต้องการจะทำโดยไม่มีค่าใช้จ่ายสูงมาก)

— Peter Bernier

คุณจะต้องตรวจสอบmvccontrib.codeplex.com (MVC Contrib) สิ่งนี้ให้ความช่วยเหลือที่ไม่ได้มีอยู่ในภาษาหลักและแนะนำในหนังสือ "Test-Drive ASP.NET MVC" (โปรแกรมเมอร์ในทางปฏิบัติ) ฉันยังคิดว่าซีลีเนียมนั้นเหมาะกับการทดสอบดูมากขึ้น

— Berin Loritsch

TestHelper (MVC Contrib): mvccontrib.codeplex.com/…

— Berin Loritsch

ซีลีเนียม (ในกรณีของฉันซีลีเนียม RC) คือสิ่งที่ฉันจะใช้สำหรับการทดสอบการรวมระบบของฉัน สิ่งที่ฉันต้องการคือความล้มเหลวที่จะเกิดขึ้นก่อนจุดนั้น

— Peter Bernier

2

@Peter: ความคิดเห็นของคุณเกี่ยวกับความพยายามของคุณในการ "ไม่ใช่เรื่องไร้สาระ" เป็นเหตุผลที่ทำให้มุมมองการทดสอบหน่วยดูขมวดคิ้ว ดังนั้นกลยุทธ์ทั่วไปคือการทำให้มุมมองบางที่สุด (เช่นไม่มีตรรกะทางธุรกิจ) ดังนั้นการทดสอบหน่วยส่วนใหญ่สามารถเกิดขึ้นที่อื่น (โดยทั่วไปใน ViewModel) มุมมองที่ตัวเองสามารถตรวจสอบได้โดยการตรวจสอบภาพหรือด้วยเครื่องมือทดสอบ UI เช่นซีลีเนียม

— Robert Harvey

7

ฉันจะไม่บอกว่ามันขมวดคิ้ว แต่ความเชื่อมั่นนั้นเป็นผลมาจากความจริงที่ว่าการทดสอบหน่วยมุมมอง MVC (อย่างน้อยก็ในความหลากหลายของ aspx) นั้นค่อนข้างยากเพราะมุมมอง aspx มีการพึ่งพา WebForms มากเกินไปซึ่งเป็นสิ่งที่ไม่สามารถพิสูจน์ได้ ดังนั้นการโต้แย้งจึงไม่คุ้มค่ากับความพยายามเพราะมุมมองมีแนวโน้มที่จะไม่ซับซ้อน

แน่นอนว่าการดูมีความซับซ้อนค่อนข้างมาก

— marcind
แหล่งที่มา

3

มุมมอง ASP.NET MVC ไม่ได้เชื่อมโยงกับ Webforms เท่าที่ฉันทราบ ไม่ใช่หนึ่งในประเด็นสำคัญสำหรับ ASP.NET MVC ที่ไม่ใช่ Webforms ใช่ไหม

— อดัมเลียร์

มุมมองของฉันคือการใช้ความพยายามของมนุษย์ในการเขียนการทดสอบการรวมเพื่อให้ครอบคลุม UI มากกว่าที่จะเขียน 'การทดสอบหน่วย' จริงเพื่อครอบคลุมมุมมอง นั่นเป็นเหตุผลที่ฉันพยายามเข้าใจความต้านทานบางอย่างที่ดูเหมือนว่ามีต่อการเขียนการทดสอบหน่วยสำหรับมุมมอง

— Peter Bernier

@Anna Aspx views ถูกสร้างขึ้นจาก WebForms พวกมันได้มาจากSystem.Web.UI.WebControls.Pageคลาสใช้<asp:ContentPlaceholder>การควบคุมเป็นต้นวิธีที่ MVC เรียกใช้พวกมันจะหลีกเลี่ยงขั้นตอนการเรียกใช้เพจจำนวนมากซึ่งโดยทั่วไปจะเชื่อมโยงกับ WebForms แต่มันก็ยังใช้ WebForms จำนวนมากภายใต้หน้าปก

— marcind

หากคุณใช้เอ็นจิ้นการดูอื่น (เช่นมีดโกน) คุณควรสามารถย้ายออกห่างจากเอ็นจิ้น Webforms

— มัฟฟินแมน

6

ฉันไม่แน่ใจว่ามันขมวดคิ้ว Testability เป็นหนึ่งในผลประโยชน์ที่สำคัญของการใช้ ASP.NET MVC ตรวจสอบบล็อกของ Steve Sandersonสำหรับข้อมูลเพิ่มเติมเกี่ยวกับเรื่องนี้

นอกจากนี้เขายังเขียนหนังสือ ASP.MVC ที่ดีที่สุดแบบคัดลอกออกมาที่นั่น ไม่เพียง แต่เขาจะสอน MVC เท่านั้น แต่เขายังได้สอนการปฏิบัติที่ดีที่สุดรอบ ๆ รวมถึงการทดสอบด้วย

ฉันคิดว่าฉันต้องอธิบายให้ชัดเจนในมุมมองการทดสอบหน่วย - คุณสามารถสร้างการทดสอบหน่วยรอบ ๆ ผลลัพธ์ที่ส่งคืนจากคอนโทรลเลอร์ (ActionResult และอื่น ๆ ) คุณจะต้องทำการทดสอบอื่น ๆ สำหรับการโต้ตอบ UI และ UI จริง

— Mark Freedman
แหล่งที่มา

"คุณยังต้องทำการทดสอบอื่น ๆ สำหรับการโต้ตอบ UI และ UI จริง" นั่นคือประเด็นที่ฉันถาม .. ทำไมการทดสอบ UI ถึงกลายเป็นส่วนหนึ่งของ 'การทดสอบอื่น' (เช่นการทดสอบการรวม) ฉันเห็นเนื้อหามากมายของ Steve Sanderson และนั่นเป็นสิ่งที่ทำให้ฉันเริ่มต้นเส้นทางนี้โดยทั่วไปพยายามทำซ้ำสิ่งที่เขาทำกับโครงการ 'MvcFakes' ของเขาและพบปัญหาในการเขียนโค้ดของเขาสำหรับรุ่น MVC รุ่นเก่า .

— Peter Bernier

1

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

— Jaypee
แหล่งที่มา