ฉันเพิ่งจบการศึกษาระดับปริญญาใน CS และตอนนี้ฉันมีงานเป็นนักพัฒนาจูเนียร์. NET (C #, ASP.NET และแบบฟอร์มเว็บ) ย้อนกลับไปเมื่อฉันยังอยู่ในมหาวิทยาลัยเรื่องของการทดสอบหน่วยได้รับความคุ้มครอง แต่ฉันไม่เคยเห็นประโยชน์ของมันเลย ฉันเข้าใจสิ่งที่ควรทำคือระบุว่าบล็อกของรหัสนั้นเหมาะสมกับการใช้งานหรือไม่ อย่างไรก็ตามฉันไม่เคยต้องเขียนบททดสอบมาก่อนและไม่เคยรู้สึกว่าจำเป็นต้องทำ

ตามที่ฉันได้กล่าวไปแล้วฉันมักจะพัฒนาด้วยเว็บฟอร์ม ASP.NET และเมื่อเร็ว ๆ นี้ฉันคิดถึงการเขียนแบบทดสอบหน่วย แต่ฉันมีคำถามสองสามข้อเกี่ยวกับเรื่องนี้

ฉันอ่านแล้วว่าการทดสอบหน่วยมักเกิดขึ้นจากการเขียน "mocks" ในขณะที่ฉันเข้าใจแนวคิดนี้ฉันไม่สามารถหาวิธีที่ฉันควรจะเขียน mocks สำหรับเว็บไซต์ที่มีการเปลี่ยนแปลงอย่างสมบูรณ์และเกือบทุกอย่างขึ้นอยู่กับข้อมูลที่มาจากฐานข้อมูล ตัวอย่างเช่นฉันใช้ล็อตซ้ำที่มีเหตุการณ์ ItemDataBound ฯลฯ (อีกครั้งขึ้นอยู่กับข้อมูลที่เป็น "ไม่ทราบ")

ดังนั้นคำถามข้อที่ 1: การเขียนการทดสอบหน่วยสำหรับเว็บ ASP.NET เป็นสิ่งที่ทำบ่อยและถ้าเป็น: ฉันจะแก้ไขปัญหา "สภาพแวดล้อมแบบไดนามิก" ได้อย่างไร

เมื่อฉันพัฒนาฉันต้องผ่านการลองผิดลองถูกมากมาย นั่นไม่ได้หมายความว่าฉันไม่รู้ว่าฉันกำลังทำอะไร แต่ฉันหมายความว่าฉันมักจะเขียนโค้ดตีCtrl F5และดูว่าเกิดอะไรขึ้น ในขณะที่วิธีการนี้ทำงานได้เกือบตลอดเวลาบางครั้งฉันก็รู้สึกว่าตัวเองไร้ความรู้สึกเล็ก ๆ น้อย ๆ (เพราะประสบการณ์น้อยของฉัน) บางครั้งฉันก็เสียเวลาเช่นนี้เช่นกัน

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

ในความคิดของฉัน: ใช่พวกเขาเป็นและใช่คุณควร

1. พวกเขาให้ความมั่นใจกับคุณในการเปลี่ยนแปลงที่คุณทำ (ทุกอย่างยังทำงานอยู่) ความมั่นใจนี้เป็นสิ่งที่คุณต้องการในการสร้างรหัสมิฉะนั้นคุณอาจกลัวที่จะเปลี่ยนแปลงสิ่งต่าง ๆ

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

3. พวกเขาทำหน้าที่เป็นเอกสารสำหรับนักพัฒนาอื่น ๆ เกี่ยวกับวิธีการทำงานของรหัสของคุณและวิธีการใช้งาน

ปัญหาแรกที่คุณเผชิญคือ ASP.NET ในตัวมันเองไม่ได้ช่วยให้คุณเขียนการทดสอบหน่วย - จริง ๆ แล้วมันทำงานได้ดีกับคุณ หากคุณมีทางเลือกให้เริ่มใช้ASP.NET MVCซึ่งสร้างขึ้นโดยคำนึงถึงการทดสอบหน่วย หากคุณไม่สามารถใช้ ASP.NET MVC ได้คุณควรใช้รูปแบบMVPใน ASP.NET ดังนั้นอย่างน้อยคุณก็สามารถทดสอบตรรกะของคุณได้อย่างง่ายดาย

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

ฉันอยากจะแนะนำให้คุณฝึกฝนและจับคู่โปรแกรม ในขณะที่อ่าน:

• การพัฒนาซอฟต์แวร์หลักการรูปแบบและการปฏิบัติที่คล่องตัว [ปกแข็ง]
• รูปแบบการออกแบบหัวแรก
• GOF Design พระคัมภีร์ลวดลาย
• การแนะนำครั้งแรกของ Roy osherove สำหรับการทดสอบหน่วย
• รูปแบบการทดสอบหน่วยพระคัมภีร์

หรือสำหรับภาพรวมแรก:

• SOLID
• รูปแบบการทดสอบ Xunit

เลขที่

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

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

Djikstra ทิ้งแนวคิดของการทดสอบในฐานะวิธีพิสูจน์ความถูกต้องย้อนกลับไปในปี 1988 และสิ่งที่เขาเขียนนั้นยังคงใช้ได้ในปัจจุบัน:

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

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

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

มีรายงานบางส่วนของการทดสอบอัตโนมัติซึ่งมีประโยชน์อย่างแท้จริงในกรณีที่ความเสถียรและความน่าเชื่อถือมีความสำคัญยิ่ง ตัวอย่างเช่นโครงการฐานข้อมูล SQLite แต่สิ่งที่ต้องใช้เพื่อให้ได้ระดับความน่าเชื่อถือนั้นไม่คุ้มค่าอย่างมากสำหรับโครงการส่วนใหญ่: อัตราส่วนการทดสอบต่อโค้ด SQLite ที่เกิดขึ้นจริงเกือบ 1,200: 1 โครงการส่วนใหญ่ไม่สามารถจ่ายได้และไม่ต้องการอยู่ดี

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

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

นี่คือภาพความสนุกด้วย ...

ฉันพบภาพนี้ที่นี่:
http://www.howtogeek.com/102420/geeks-versus-non-geeks-when-doing-repetitive-tasks-funny-chart/

การทดสอบหน่วยมีบางสิ่งที่ลึกลับเกี่ยวกับมันในทุกวันนี้ ผู้คนปฏิบัติต่อมันราวกับว่าการทดสอบครอบคลุม 100% นั้นเป็นจอกศักดิ์สิทธิ์และราวกับว่าการทดสอบหน่วยเป็นหนทางหนึ่งที่แท้จริงในการพัฒนาซอฟต์แวร์

พวกเขากำลังพลาดจุด

การทดสอบหน่วยไม่ใช่คำตอบ การทดสอบคือ

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

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

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

เครื่องใช้บนมืออื่น ๆ ที่เป็นที่ยอดเยี่ยมในการปฏิบัติงานที่น่าเบื่อและใช้เวลานาน นั่นคือสิ่งที่คอมพิวเตอร์คิดค้นขึ้นมา

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

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

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

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

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

TL; DR: ไม่ต้องกังวลกับการทดสอบหน่วยในตอนนี้ เพียงแค่กังวลเกี่ยวกับการทดสอบซอฟต์แวร์ของคุณก่อน

มันขึ้นอยู่กับ

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

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

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

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

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

เรามาถึงจุดที่สำคัญมากอย่างหนึ่ง - ถดถอย ที่ทำงานฉันมีสองทีมที่ดูแลสองแอพ ครั้งแรกเมื่อประมาณ 5-6 ปีก่อนโดยมีการทดสอบรหัสน้อยมาก * และรุ่นที่สองซึ่งเป็นเวอร์ชั่นที่ใหม่กว่าของแอปพลิเคชันแรกที่มีชุดการทดสอบแบบเต็มเป่า (หน่วยการรวมและสิ่งอื่นใด) ทั้งสองทีมมีการทดสอบด้วยตนเอง (มนุษย์) โดยเฉพาะ ต้องการทราบว่าใช้เวลานานแค่ไหนในการแนะนำคุณสมบัติพื้นฐานที่ค่อนข้างใหม่สำหรับทีมแรก? 3 ถึง 4 สัปดาห์ ครึ่งหนึ่งของเวลานี้คือ "ตรวจสอบว่าทุกอย่างยังใช้งานได้อยู่" นี่เป็นเวลาว่างสำหรับผู้ทดสอบด้วยตนเอง โทรศัพท์ดังขึ้นคนอารมณ์เสียมีบางอย่างเสียอีก ทีมที่สองมักจะจัดการกับปัญหาดังกล่าวในเวลาน้อยกว่า 3 วัน

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

และสุดท้าย แต่ไม่ท้ายสุดความคิดเห็นจากไบรอันซึ่งฉันคิดว่าเป็นประเด็นสำคัญ

(... ) พวกเขาเพิ่มความมั่นใจของคุณ (หรือควร ... ) ว่ารหัสทำในสิ่งที่คุณออกแบบให้ทำและจะทำต่อไปในวันพรุ่งนี้สิ่งที่ทำในวันนี้

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

_{* พวกเขาทำการทดสอบอย่างช้า ๆ เกี่ยวกับฐานรหัสของพวกเขา แต่เราทุกคนรู้ว่าสิ่งเหล่านี้มักจะมีลักษณะอย่างไร}

กำลังเขียนการทดสอบหน่วยสำหรับ webforms ASP.NET สิ่งที่ทำบ่อยและถ้าเป็น: ฉันจะแก้ไขปัญหา "สภาพแวดล้อมแบบไดนามิก" ได้อย่างไร

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

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

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

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

อันนี้โอเค.

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

ฉันเพิ่งจบการศึกษาระดับปริญญาใน CS และปัจจุบันฉันมีงานเป็นนักพัฒนาจูเนียร์. NET (ใน C # และมักจะ ASP.NET รูปแบบเว็บ - ไม่ใช่ ASP.NET MVC) ย้อนกลับไปเมื่อฉันยังอยู่ในมหาวิทยาลัยเรื่องของการทดสอบหน่วยได้รับความคุ้มครอง แต่ฉันไม่เคยเห็นประโยชน์ของมันเลย

นั่นเป็นเพราะคุณไม่เคยตั้งโปรแกรมใหญ่

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

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

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

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

- พวกคุณแนะนำให้ฉันเริ่มเขียนการทดสอบหน่วยหรือไม่?

ใช่. อ่าน"การพัฒนาแบบทดสอบขับเคลื่อน"ของเบ็คก่อน

ฉันคิดว่ามันอาจช่วยฉันในการใช้งานจริง แต่จากนั้นอีกครั้งฉันรู้สึกว่ามันอาจทำให้ฉันช้าลง

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

คำแนะนำใด ๆ ที่จะได้รับการชื่นชม :)

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

แก้ไข: แน่นอนว่าฉันได้เข้าร่วมคำถาม TDD pro / con dogpile และข้ามไป # 1:

1 - การนำการทดสอบหน่วยไปใช้ในฟอร์มเว็บ ASP.net:

ก่อนอื่นถ้าคุณคิดว่าคุณสามารถพาพวกเขาไปด้วย MVC ต่อสู้เพื่อมันเหมือนถ้ำที่บ้าคลั่ง ในฐานะส่วนหน้า / UI dev, .net MVC เป็นสิ่งที่ช่วยให้ฉันหยุดเกลียด. net ดังนั้นฉันจึงสามารถมีสมาธิที่ดีขึ้นในการเกลียดการแก้ปัญหาเว็บ Java ทุกเว็บที่ฉันเคยพบเจอ การทดสอบหน่วยเป็นปัญหาเนื่องจากเว็บฟอร์มทำให้เส้นแบ่งระหว่างเซิร์ฟเวอร์และฝั่งไคลเอ็นต์จริง ๆ ในความพยายามใด ๆ ที่จะทำการทดสอบหน่วยฉันจะให้ความสำคัญกับการจัดการข้อมูลและ (หวังว่า) เว็บฟอร์มจะจัดการกับการป้อนข้อมูลผู้ใช้ให้เป็นมาตรฐานสำหรับคุณภายใต้ประทุน

2 - ในการทดสอบหน่วยว่าคุ้มค่าในครั้งแรก:

เอาล่ะการเปิดเผยแบบเต็ม:

• ฉันเรียนรู้ด้วยตนเองเป็นส่วนใหญ่ การฝึกอบรมอย่างเป็นทางการของฉันทำให้เหมือน JavaScript, PHP และคลาส C และการศึกษาส่วนตัวของฉันเกี่ยวกับหลักการ OOP และการอ่านจากสิ่งต่าง ๆ เช่นลวดลายการออกแบบ

อย่างไรก็ตาม

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

หมายความว่าฉันไม่ได้เขียนคอมไพเลอร์หรือเครื่องเสมือน ฉันเขียนเพื่อการตีความที่แตกต่างกันเช่น 4-20 ภาษาสามภาษา (ใช่ทั้งสองเป็นเพียงการประกาศ แต่ยังกำหนดพื้นที่ทางกายภาพพื้นฐานของ UI ที่ฉันทำงานด้วยวิธีที่แตกต่างกันในบางครั้ง) และได้ทำเช่นนั้นเนื่องจากการตีความเป็น มีความหลากหลายมากกว่าในทุกวันนี้ และไม่ใช่ฉันไม่ใช่แค่เด็กบางคนที่เสียบ JQuery stuff สำหรับแอพที่ใช้แล้วทิ้ง ฉันช่วยสร้างและรักษาสิ่งที่ค่อนข้างซับซ้อนด้วยความซับซ้อนขององค์ประกอบ UI จำนวนมาก

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

ความเข้าใจของฉันเกี่ยวกับสิ่งที่ TDD ควรจะทำเพื่อคุณคือการทดสอบนั้นเกี่ยวกับการบังคับให้คุณพิจารณาการออกแบบอย่างระมัดระวังมากขึ้นและให้ความสำคัญกับข้อกำหนดต่างๆ ยุติธรรมเพียงพอ แต่ปัญหาตรงนี้คือมันล้มล้างสิ่งที่คุณควรทำซึ่งออกแบบให้อินเทอร์เฟซเป็นสิ่งที่ละเอียดอ่อน แต่แตกต่างกันโดยพื้นฐานซึ่งออกแบบมาเพื่อทดสอบอินเทอร์เฟซ ความแตกต่างสำหรับฉันคือระหว่างการวาดภาพที่ชัดเจนว่าแม่ไม่ต้องเดาความหมายและเติมทั้งหน้าด้วยสีเขียวอย่างรวดเร็วจริง ๆ เพื่อที่คุณจะได้เป็นเด็กคนแรกที่ตบสีเทียนของเขาลงบนโต๊ะแล้วตะโกนว่า "เสร็จแล้ว! " ด้วยการเปลี่ยนลำดับความสำคัญเป็นผลลัพธ์ผ่านกระบวนการและการออกแบบคุณจะต้องสนับสนุนการติดตั้งรหัสขยะอย่างต่อเนื่องซึ่งโดยทั่วไปคือสิ่งที่เป็นสาเหตุของปัญหาของคุณตั้งแต่แรก

และแน่นอนว่ามี "ไม่จริงจุดของ" ยังได้รับการยกย่องด้านผลประโยชน์ของหน่วยทดสอบเองช่วยให้คุณตรวจสอบข้อผิดพลาดการถดถอย ผู้สนับสนุน TDD มักจะขัดสนเล็กน้อยว่านี่เป็นเป้าหมายหรือเป็นผลข้างเคียงที่ดี IMO เพราะพวกเขารู้ดีหรือสงสัยอย่างน้อยก็ว่ามันไม่เพียงพอที่จะสร้างข้อบกพร่องในตัวคุณ โค้ดโดยเฉพาะอย่างยิ่งในภาษาที่มีไดนามิกมากขึ้นเช่น JavaScript ซึ่งสมมติว่าคุณสามารถคาดการณ์สถานการณ์ที่เป็นไปได้ทุกอย่างในการพึ่งพาระยะยาว

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

จากทั้งหมดข้างต้นได้ช่วยฉันลดข้อผิดพลาดที่ยากต่อการวินิจฉัยในรหัสของฉันอย่างจริงจังและคุณสามารถไว้วางใจได้ว่านั่นเป็นสิ่งสำคัญอันดับแรกสำหรับคนที่มาเป็นนักพัฒนาซอฟต์แวร์โดยมีชุดเบราว์เซอร์ที่ไม่มีอะไรจะดีไปกว่า เอ่อมีปัญหากับวัตถุประเภท 'วัตถุ' ที่หมายเลขบรรทัดจินตภาพนี้ในไฟล์ที่ไม่ได้ระบุ " (gee ขอบคุณ IE6) TDD ในสายงานของฉันจะไม่สนับสนุนสิ่งเหล่านี้ มันจะเปลี่ยนโฟกัสไปที่ผลลัพธ์ 100% ผ่านกระบวนการซึ่งสิ่งที่อยู่ระหว่างจุด A และ B นั้นไม่สำคัญว่าจะใช้งานได้จริง เป็นการเสียเวลาที่จะนำไปใช้ที่ดีขึ้นเพื่อให้แน่ใจว่าข้อมูลของคุณอ่านง่ายพกพาง่ายและปรับเปลี่ยนได้โดยไม่เกิดความสับสนในครั้งแรก

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

จากประสบการณ์ของฉันการทดสอบหน่วยมีประโยชน์มากจริง ๆเมื่อคุณเริ่มต้นกับพวกเขาและอยู่กับพวกเขาเช่นการพัฒนาทดสอบขับเคลื่อน นี่คือเหตุผล:

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

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

• การทดสอบหน่วยช่วยให้คุณสามารถ "รหัสโดยการทดสอบ" เครื่องมือ refactoring เช่น ReSharper สามารถเป็นเพื่อนที่ดีที่สุดของคุณถ้าคุณปล่อยมัน คุณสามารถใช้มันเพื่อกำหนดโครงกระดูกของฟังก์ชั่นใหม่ในขณะที่คุณกำลังกำหนดการใช้งานในการทดสอบ

  ตัวอย่างเช่นสมมติว่าคุณต้องสร้างวัตถุใหม่ MyClass คุณเริ่มต้นด้วยการสร้างอินสแตนซ์ของ MyClass "แต่ MyClass ไม่มีอยู่!" ReSharper บ่น "จากนั้นสร้างมันขึ้นมา" คุณพูดด้วยการกด Alt + Enter และโอมเพี้ยงคุณมีคำจำกัดความของคลาส ในบรรทัดถัดไปของรหัสทดสอบคุณเรียกเมธอด MyMethod "แต่นั่นไม่ได้มีอยู่!" ReSharper พูดว่า "จากนั้นสร้างมันขึ้นมา" คุณทำซ้ำโดยใช้ Alt + Enter อื่น คุณมีการกดปุ่มสองสามครั้งเพื่อกำหนด "โครงกระดูก" ของรหัสใหม่ของคุณ ในขณะที่คุณยังคงใช้งานได้อย่างต่อเนื่อง IDE จะแจ้งให้คุณทราบเมื่อมีบางสิ่งที่ไม่เหมาะสมและโดยปกติแล้วการแก้ปัญหานั้นง่ายพอที่ IDE หรือเครื่องมือที่เสียบเข้ากับมันจะรู้วิธีแก้ไข

  อีกตัวอย่างที่สอดคล้องกับโมเดล "Triple-A"; "จัดการทำหน้าที่ยืนยัน" ตั้งค่าทุกอย่างดำเนินการตรรกะจริงที่คุณกำลังทดสอบจากนั้นยืนยันว่าตรรกะนั้นถูกต้อง การเข้ารหัสในลักษณะนี้มันเป็นเรื่องธรรมดามากที่จะเขียนรหัสการแก้ปัญหาในการทดสอบ จากนั้นด้วยการกดปุ่มเพียงไม่กี่ครั้งคุณสามารถแยกลอจิกนั้นและวางไว้ที่ไหนสักแห่งที่สามารถใช้ในรหัสการผลิตจากนั้นทำการเปลี่ยนแปลงเล็กน้อยกับการทดสอบที่ชี้ไปที่ตำแหน่งใหม่ของตรรกะ การทำเช่นนี้บังคับให้คุณสร้างรหัสในรูปแบบโมดูลาร์ที่ง่ายต่อการใช้ซ้ำเพราะหน่วยที่คุณกำลังทดสอบจะต้องสามารถเข้าถึงได้

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

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

  หากนักพัฒนาต้องค้นหาด้วยตนเองและทดสอบทุกบรรทัดของรหัสที่อาจได้รับผลกระทบจากการเปลี่ยนแปลงที่อาจเกิดขึ้นจะไม่มีอะไรทำเลยเพราะค่าใช้จ่ายในการพิจารณาผลกระทบของการเปลี่ยนแปลงจะทำให้การเปลี่ยนแปลงนั้นเป็นไปไม่ได้ อย่างน้อยที่สุดไม่มีสิ่งใดที่จะเป็นของแข็งและดูแลรักษาได้ง่ายเพราะคุณจะไม่กล้าสัมผัสสิ่งที่อาจใช้ในหลาย ๆ ที่; คุณควรจะเปลี่ยนวิธีการแก้ปัญหาที่คล้ายกัน แต่มีการผสมผสานของคุณเองเล็กน้อยสำหรับกรณีนี้ละเมิด SRP และ OCP และ OCP และเปลี่ยนรหัสฐานของคุณเป็นผ้าห่มเย็บปะติดปะต่อกันอย่างช้าๆ

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

• การทดสอบหน่วยแสดงว่ารหัสการทำงานแทนการพิสูจน์ผลงานรหัส ได้อย่างรวดเร็วก่อนคุณอาจคิดว่าเป็นข้อเสีย; แน่นอนพิสูจน์ได้ดีกว่าการสาธิต? ทฤษฎียอดเยี่ยม ทฤษฎีการคำนวณและอัลกอริทึมเป็นพื้นฐานของงานของเรา แต่หลักฐานทางคณิตศาสตร์ของความถูกต้องของขั้นตอนวิธีการคือไม่ได้พิสูจน์ความถูกต้องของการดำเนินงาน หลักฐานทางคณิตศาสตร์แสดงให้เห็นว่ารหัสที่ปฏิบัติตามอัลกอริทึมควรถูกต้องเท่านั้น การทดสอบแสดงให้เห็นว่าหน่วยรหัสเขียนจริงไม่สิ่งที่คุณคิดว่ามันจะทำและดังนั้นจึงเป็นหลักฐานที่มันเป็นที่ถูกต้อง โดยทั่วไปแล้วจะมีคุณค่ามากกว่าทุกบทพิสูจน์ทางทฤษฎี

ตอนนี้สิ่งที่กล่าวมามีข้อเสียในการทดสอบหน่วย:

• คุณไม่สามารถทดสอบทุกสิ่งได้. คุณสามารถออกแบบระบบของคุณเพื่อลดจำนวน LOC ที่ไม่ครอบคลุมโดยการทดสอบหน่วย แต่จะมีเพียงบางส่วนของระบบที่ไม่สามารถทำการทดสอบหน่วยได้ เลเยอร์การเข้าถึงข้อมูลของคุณสามารถล้อเลียนเมื่อใช้โดยรหัสอื่น แต่เลเยอร์การเข้าถึงข้อมูลนั้นมีผลข้างเคียงมากมายและโดยทั่วไปจะไม่สามารถทำการทดสอบหน่วย (Repository หรือ DAO) ได้มาก ในทำนองเดียวกันรหัสที่ใช้ไฟล์ตั้งค่าการเชื่อมต่อเครือข่าย ฯลฯ มีผลข้างเคียงในตัวและคุณไม่สามารถทดสอบบรรทัดโค้ดที่ทำเช่นนั้นได้ องค์ประกอบ UI มักไม่สามารถทดสอบหน่วยได้ คุณสามารถทดสอบวิธีการ codebehind เช่นตัวจัดการเหตุการณ์คุณสามารถทดสอบตัวสร้างหน่วยงานและตรวจสอบว่ามีการเสียบตัวจัดการ แต่ก็ไม่มีการแทนที่ในรหัสสำหรับผู้ใช้คลิกเมาส์บนองค์ประกอบกราฟิกที่เฉพาะเจาะจงและดูตัวจัดการเรียกว่า การเข้าถึงขอบเขตเหล่านี้ระหว่างสิ่งที่สามารถและไม่สามารถทดสอบได้อย่างเพียงพอเรียกว่า "การขูดขอบของกล่องทราย" นอกเหนือจากจุดนั้นคุณ จำกัด การใช้การทดสอบการรวมการทดสอบการยอมรับอัตโนมัติและการทดสอบด้วยตนเองเพื่อตรวจสอบพฤติกรรม

• ข้อดีหลายประการของการทดสอบหน่วยใช้ไม่ได้หากไม่มี TDD. มันเป็นไปได้อย่างสมบูรณ์แบบในการเขียนโค้ดจากนั้นเขียนการทดสอบที่ออกกำลังกายรหัส พวกเขายังคงเป็น "การทดสอบหน่วย" แต่โดยการเขียนโค้ดก่อนคุณจะเสียข้อดีหลายประการในการพัฒนา "การทดสอบครั้งแรก": รหัสไม่จำเป็นต้องมีการออกแบบในลักษณะที่สามารถทดสอบได้ง่ายหรือแม้แต่ใช้ในการผลิต ; คุณไม่ได้รับกระบวนการคิด "ตรวจสอบอีกครั้ง" โดยธรรมชาติในการเขียนแบบทดสอบและคิดเกี่ยวกับสิ่งที่คุณไม่ได้คิด คุณไม่ได้รหัสโดยการทดสอบ; และถ้าคุณเขียนโค้ดให้ทดสอบด้วยตนเองและดูว่ามันทำงานได้หรือไม่จากนั้นให้โค้ดทดสอบหน่วยที่ล้มเหลวซึ่งผิดรหัสหรือการทดสอบ ข้อได้เปรียบหลักของคุณคือการป้องกันการถดถอย (คุณจะได้รับการแจ้งเตือนเมื่อรหัสที่ผ่านการทดสอบก่อนหน้านี้ล้มเหลว) และการตรวจสอบความเร็วสูงเมื่อเทียบกับการทดสอบด้วยตนเอง การสูญเสีย TDD '

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

• การทดสอบหน่วยต้องมีระเบียบวินัย. คุณต้องเขียนการทดสอบที่จะออกกำลังกายอย่างเพียงพอ codebase (ครอบคลุมรหัสที่ดี) คุณต้องทำงานอย่างสม่ำเสมอ (เช่นเมื่อใดก็ตามที่คุณทำการเปลี่ยนแปลงชุดเต็มควรจะทำงาน) และคุณต้องรักษาทุกอย่าง "สีเขียว" ( การทดสอบทั้งหมดผ่าน) เมื่อสิ่งต่าง ๆ แตกคุณต้องแก้ไขด้วยการแก้ไขรหัสที่ไม่ตรงตามความคาดหวังหรือโดยการอัพเดทความคาดหวังของการทดสอบ หากคุณเปลี่ยนการทดสอบคุณควรถามว่า "ทำไม" และเฝ้าดูตัวเองอย่างใกล้ชิด มันเป็นการดึงดูดอย่างไม่น่าเชื่อเพียงแค่เปลี่ยนการยืนยันที่ล้มเหลวเพื่อให้ตรงกับพฤติกรรมปัจจุบันหรือเพียงแค่ลบการทดสอบที่ล้มเหลวออกไป แต่การทดสอบเหล่านั้นควรเป็นไปตามข้อกำหนดและเมื่อการทดสอบทั้งสองไม่ตรงกับที่คุณมีปัญหา หากสิ่งเหล่านี้ยังไม่เสร็จ

• การทดสอบหน่วยต้องใช้อุปกรณ์เพิ่มเติม. วิธีแก้ปัญหาตามปกติสำหรับความมีระเบียบวินัยและแนวโน้มตามธรรมชาติของมนุษย์ที่จะขี้เกียจและ compacent คือ "build-bot" ที่รันแพ็คเกจซอฟต์แวร์ "Integration Integration" อย่างต่อเนื่องเช่น TeamCity, CruiseControl เป็นต้นซึ่งทำการทดสอบหน่วยคำนวณ ตัวชี้วัดความครอบคลุมโค้ดและมีการควบคุมอื่น ๆ เช่น "triple-C" (การปฏิบัติตามข้อกำหนดการเข้ารหัส a la FxCop) ฮาร์ดแวร์สำหรับ build-bot จะต้องมีประสิทธิภาพพอสมควร (ไม่เช่นนั้นจะไม่ทันกับอัตราการตรวจสอบโค้ดที่ทีมเฉลี่ยจะทำ) และขั้นตอนการเช็คอินบน bot จะต้องได้รับการอัพเดท (ถ้า ไลบรารีใหม่ของการทดสอบหน่วยถูกสร้างขึ้นสร้างสคริปต์ที่เรียกใช้การทดสอบหน่วยต้องเปลี่ยนเพื่อค้นหาในไลบรารีนั้น) มันใช้งานได้น้อยกว่าที่คิด แต่โดยทั่วไปต้องใช้ความเชี่ยวชาญด้านเทคนิคในส่วนของคนอย่างน้อยสองสามคนในทีมที่รู้ว่า nitty gritty ของกระบวนการสร้างต่างๆทำงานอย่างไร (และสามารถทำให้เป็นอัตโนมัติในสคริปต์และบำรุงรักษาสคริปต์ดังกล่าว) นอกจากนี้ยังต้องมีวินัยในรูปแบบของการให้ความสนใจเมื่อบิลด์ "หยุด" และแก้ไขสิ่งที่ทำให้บิลด์ (ถูกต้อง) ก่อนที่จะตรวจสอบสิ่งใหม่ ๆ

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

• การทดสอบหน่วยโดยทั่วไปห้ามรูปแบบการเข้ารหัส "การพัฒนาแอปพลิเคชันอย่างรวดเร็ว". หากคุณกำลังเขียนการทดสอบหน่วยคุณไม่ได้เขียนโปรแกรม "เร็วและหลวม" โดยทั่วไปจะเป็นสิ่งที่ดี แต่เมื่อคุณอยู่ภายใต้เส้นตายที่กำหนดจากนอกการควบคุมของคุณหรือคุณกำลังดำเนินการเปลี่ยนแปลงเล็ก ๆ น้อย ๆ และผู้มีส่วนได้เสีย (หรือเจ้านายของคุณ) สงสัยว่าทำไม cruft ทั้งหมดนี้จึงเกิดขึ้น เปลี่ยนรหัสหนึ่งบรรทัดสามารถเขียนและบำรุงรักษาชุดทดสอบหน่วยที่เหมาะสมได้อย่างง่ายดาย โดยทั่วไปกระบวนการที่คล่องตัวจะช่วยในเรื่องนี้โดยอนุญาตให้ผู้พัฒนาพูดในเวลาที่กำหนด โปรดจำไว้ว่าพนักงานขายทุกคนต้องทำคือพูดว่า "ใช่เราทำได้" และพวกเขาจะได้รับการตรวจสอบค่าคอมมิชชั่นเว้นแต่กระบวนการนั้นจะเกี่ยวข้องกับผู้ที่ต้องทำงานจริงโดยบอกว่า "ไม่เราไม่สามารถทำได้" และให้ความสนใจ แต่ไม่ใช่ Agile ของทุกคนและ Agile มีข้อ จำกัด ของตัวเอง

การทดสอบหน่วยจะมีประโยชน์เมื่อใช้อย่างถูกต้อง ตรรกะของคุณมีปัญหาหลายอย่าง

"เมื่อฉันพัฒนาฉันต้องผ่านการลองผิดลองถูกมากมาย" เควินกล่าว

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

s writing unit tests for ASP.NET web forms something that is done often

ฉันไม่มีความรู้เกี่ยวกับข้อมูลทางสถิติที่จะบอกว่าคนทดสอบเว็บฟอร์มบ่อย ไม่เป็นไร. UI นั้นยากต่อการทดสอบและไม่ควรใช้การทดสอบหน่วยร่วมกับ UI แยกตรรกะของคุณออกเป็นเลเยอร์ไลบรารีคลาสที่สามารถทดสอบได้ ทดสอบ UI แยกต่างหากจากตรรกะส่วนหลัง

So, question number 2: Would you guys advise me to start writing unit tests?

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

ในระดับปฏิบัติการทดสอบหน่วยจะมีประโยชน์อย่างยิ่งสำหรับเหตุผลที่สำคัญอย่างหนึ่ง: คุณสามารถทดสอบทีละหนึ่งบิตของรหัส

เมื่อคุณเขียนลำดับขั้นตอนที่ซับซ้อนทั้งหมดและตรวจแก้จุดบกพร่องในตอนท้ายคุณมักจะพบข้อบกพร่องมากมายและโดยทั่วไปกระบวนการจะยากขึ้นเพราะคุณอยู่ในกระบวนการต่อไป ใน Visual Studio คุณสามารถสร้างการทดสอบอย่างรวดเร็วเปลี่ยนมันเล็กน้อยและรันเฉพาะการทดสอบนั้น .. จากนั้นคุณจะรู้ว่าสำหรับวิธีการที่เรียกวิธีการนั้นสามารถพึ่งพาได้ ดังนั้นมันจึงเพิ่มความมั่นใจ

การทดสอบหน่วยไม่ได้พิสูจน์ว่าโปรแกรมของคุณถูกต้อง! : การทดสอบหน่วยตรวจสอบการถดถอยในโค้ดที่ละเอียดอ่อนและอนุญาตให้คุณทดสอบวิธีการใหม่ที่คุณเขียน

การทดสอบหน่วยไม่ได้หมายถึงการทดสอบ front-end : ลองนึกถึงการทดสอบหน่วยเป็นโครงการขนาดเล็กที่คุณสร้างขึ้นเพื่อทดสอบวิธีการใหม่ที่คุณกำลังเขียนหรือบางสิ่งบางอย่างไม่ใช่เป็นเงื่อนไขบางประการที่รหัสของคุณต้องปฏิบัติตาม

การทดสอบหน่วยใช้งานได้ดีสำหรับสภาพแวดล้อมการทำงานร่วมกัน : ถ้าฉันต้องจัดหาวิธีการให้กับเพื่อนร่วมงานที่ใช้เทคโนโลยีที่แตกต่างอย่างสิ้นเชิงกับฉันอย่างเช่นเขาโทรจาก iOS แล้วฉันสามารถเขียนการทดสอบหน่วยได้อย่างรวดเร็วเพื่อดูว่า วิธีที่เขาต้องการ a) เรียกข้อมูลที่ถูกต้องอีกครั้ง b) ดำเนินการตามข้อกำหนดของเขา c) ไม่มีคอขวดที่น่ารังเกียจ

สิ่งหนึ่งที่ดูเหมือนจะไม่ได้สัมผัสคือความซับซ้อนของการทดสอบรหัสประเภทต่างๆ

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

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

ไม่มีกระสุนเงินสิ่งที่แสดงให้เห็นว่ากระสุนเงินนั้นไม่ดีเท่าที่ผู้สนับสนุนอ้าง แต่นั่นไม่ได้หมายความว่ามันไร้ประโยชน์

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

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

จริงๆแล้วคุณอาจแนะนำการทดสอบหน่วยง่ายขึ้นมากด้วยรูปแบบ ASP.NET MVPที่สามารถใช้ในการพัฒนาแบบฟอร์มเว็บของคุณ ability to write essential unit testsมันจะมาแนะนำการแยกของความกังวลและความ

ข้อมูลอ้างอิงบางอย่างที่อาจเป็นประโยชน์ในการค้นหา ได้แก่ :

• เริ่มต้นด้วยการทดสอบแอปพลิเคชัน ASP.NET Webforms (รูปแบบ MVP)
• ดำเนินการและทดสอบการเปลี่ยนเส้นทางด้วย ASP.NET Web Forms MVP
• Model View Presenter พร้อม ASP.NET - CodeProject

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

เป็นประสบการณ์ของฉันที่ใช่การทดสอบหน่วยมีประโยชน์

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

การทดสอบหน่วยมอบสิทธิประโยชน์ต่าง ๆ :

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

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

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

อย่างไรก็ตาม ...

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

สำหรับแอปง่าย ๆ ที่มีเลเยอร์จำนวนน้อยให้ทดสอบ (หน้าต่างหลัก -> เมนูย่อย) บางทีการรวบรวมเพื่อเรียกใช้เพื่อตรวจสอบการเปลี่ยนแปลงก็โอเค

สำหรับแอพที่มีขนาดใหญ่ขึ้นซึ่งใช้การนำทางในยุค 30 เพื่อเข้าถึงหน้าเว็บที่คุณกำลังทดสอบสิ่งนี้กลายเป็นเรื่องที่แพงมาก ..

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

ฉันรู้ว่าโปรแกรมเมอร์ส่วนใหญ่ไม่ได้ออกแบบโปรแกรมอีกต่อไปฉันยังคงทำและฉันพบว่าการทดสอบหน่วยนั้นจำเป็นต้องใช้เวลาค่อนข้างมากในการปรับตัวให้เข้ากับวัฒนธรรม TDD แต่จนถึงตอนนี้ฉันได้พบเพียง 1-2 รองลงมา ข้อบกพร่องต่อการทดสอบหลายพันบรรทัดของรหัสของฉัน - ไม่ใช่แค่สิ่งที่ฉันเขียน แต่สิ่งที่ผู้ทดสอบอย่างเป็นทางการเขียนเช่นกัน

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

นี่คืออาร์กิวเมนต์ dijsktraian: การทดสอบหน่วยสามารถเรียกใช้กับโปรแกรมที่มีรายละเอียดเพียงพอที่จะเรียกใช้

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

ทุกวันนี้ไดอะแกรมของคลาสนั้นถูกสร้างขึ้นจากโค้ดซึ่งมีหลายร้อยหลายพันคลาสและไม่สามารถใช้งานได้อย่างสมบูรณ์ - อะไรก็ตามที่มีองค์ประกอบมากกว่า 15 รายการนั้นเกินกว่าที่มนุษย์จะยอมรับได้

คุณต้องรู้ว่า 10 + -5 คลาสมีความสำคัญหรือสิ่งที่คุณทำอยู่ในขณะนี้และสามารถตรวจสอบโค้ดของคุณจากหลาย ๆ มุมมองแต่ละแผนภาพแสดงถึงมุมมองที่คุณกำลังมองหาและคุณจะกำจัดแมลงนับพัน บนกระดาษ.

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

มันง่ายกว่ามาก ...

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

ฉันทำโค้ดด้วย 95 +% ของการครอบคลุมโค้ด แน่นอนฉันทำการทดสอบหน่วยบางครั้งโดยเฉพาะอย่างยิ่ง สำหรับการตรวจสอบขอบเขตในการคำนวณ แต่ฉันยังไม่ผ่านการถดถอยที่ร้ายแรง (ร้ายแรง: ไม่ถูกลบออกใน 24 ชั่วโมง) สำหรับการไม่ใช้การทดสอบหน่วยแม้กระทั่งการรีแฟคเตอร์

บางครั้งฉันไม่ได้เขียนโค้ดบรรทัดเดียวเป็นเวลา 3-4 วันแค่วาดภาพ จากนั้นในหนึ่งวันฉันจะพิมพ์เป็น 1,500-2,000 บรรทัด ในวันถัดไปพวกเขาส่วนใหญ่พร้อมผลิต บางครั้งการทดสอบหน่วยถูกเขียน (ด้วยความครอบคลุม 80 +%) บางครั้ง (นอกเหนือจาก) ผู้ทดสอบจะถูกขอให้พยายามทำลายมันทุกครั้งที่มีคนขอให้ทบทวนโดยดูที่มัน

ฉันยังไม่เห็นการทดสอบหน่วยเหล่านั้นค้นหาอะไร

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