เทคโนโลยี
การทดสอบหน่วย. NET: ใช้จ่ายล่วงหน้าเพื่อประหยัดในภายหลัง
มักจะมีความสับสนและข้อสงสัยมากมายเกี่ยวกับการทดสอบหน่วยเมื่อพูดคุยกับผู้มีส่วนได้ส่วนเสียและลูกค้า การทดสอบหน่วยบางครั้งฟังดูเหมือนการใช้ไหมขัดฟันกับเด็ก “ ฉันแปรงฟันแล้วทำไมฉันต้องทำแบบนี้”
การแนะนำการทดสอบหน่วยมักดูเหมือนเป็นค่าใช้จ่ายที่ไม่จำเป็นสำหรับผู้ที่พิจารณาวิธีการทดสอบและการทดสอบการยอมรับของผู้ใช้ที่แข็งแกร่งเพียงพอ
แต่การทดสอบหน่วยเป็นเครื่องมือที่ทรงพลังมากและง่ายกว่าที่คุณคิด ในบทความนี้เราจะมาดูการทดสอบหน่วยและมีเครื่องมืออะไรบ้างใน DotNet เช่น Microsoft.VisualStudio.TestTools และ ขั้นต่ำ .
เราจะพยายามสร้างไลบรารีคลาสอย่างง่ายที่จะคำนวณพจน์ที่ n ในลำดับฟีโบนักชี ในการทำเช่นนั้นเราจะต้องสร้างคลาสสำหรับการคำนวณลำดับฟีโบนักชีซึ่งขึ้นอยู่กับคลาสคณิตศาสตร์แบบกำหนดเองที่รวมตัวเลขเข้าด้วยกัน จากนั้นเราสามารถใช้. NET Testing Framework เพื่อให้แน่ใจว่าโปรแกรมของเราทำงานตามที่คาดไว้
การทดสอบหน่วยคืออะไร?
การทดสอบหน่วยจะแบ่งโปรแกรมออกเป็นบิตโค้ดที่เล็กที่สุดโดยปกติจะเป็นระดับฟังก์ชันและทำให้แน่ใจว่าฟังก์ชันจะส่งคืนค่าที่คาดไว้ ด้วยการใช้กรอบการทดสอบหน่วยการทดสอบหน่วยจะกลายเป็นเอนทิตีแยกต่างหากซึ่งสามารถเรียกใช้การทดสอบอัตโนมัติบนโปรแกรมได้ในขณะที่สร้างขึ้น
[TestClass] public class FibonacciTests { [TestMethod] //Check the first value we calculate public void Fibonacci_GetNthTerm_Input2_AssertResult1() { //Arrange int n = 2; //setup Mock mockMath = new Mock(); mockMath .Setup(r => r.Add(It.IsAny(), It.IsAny())) .Returns((int x, int y) => x + y); UnitTests.Fibonacci fibonacci = new UnitTests.Fibonacci(mockMath.Object); //Act int result = fibonacci.GetNthTerm(n); //Assert Assert.AreEqual(result, 1); } } การทดสอบหน่วยง่ายๆโดยใช้การทดสอบระเบียบวิธีการจัดเรียงทำหน้าที่ยืนยันว่าห้องสมุดคณิตศาสตร์ของเราสามารถเพิ่ม 2 + 2 ได้อย่างถูกต้อง
เมื่อตั้งค่าการทดสอบหน่วยแล้วหากมีการเปลี่ยนแปลงรหัสเพื่อพิจารณาเงื่อนไขเพิ่มเติมที่ไม่ทราบเมื่อพัฒนาโปรแกรมครั้งแรกตัวอย่างเช่นการทดสอบหน่วยจะแสดงว่ากรณีทั้งหมดตรงกับค่าที่คาดไว้หรือไม่ เอาต์พุตโดยฟังก์ชัน
การทดสอบหน่วยคือ ไม่ การทดสอบการรวม มันคือ ไม่ การทดสอบแบบ end-to-end แม้ว่าทั้งสองวิธีนี้จะเป็นวิธีการที่มีประสิทธิภาพ แต่ก็ควรทำงานร่วมกับการทดสอบหน่วยไม่ใช่เพื่อทดแทน
ประโยชน์และวัตถุประสงค์ของการทดสอบหน่วย
ประโยชน์ที่ยากที่สุดของการทดสอบหน่วยเพื่อทำความเข้าใจ แต่ที่สำคัญที่สุดคือความสามารถในการทดสอบรหัสที่เปลี่ยนแปลงใหม่ได้ทันที สาเหตุที่เข้าใจได้ยากก็เพราะนักพัฒนาหลายคนคิดไปเอง “ ฉันจะไม่แตะต้องฟังก์ชั่นนั้นอีกแล้ว” หรือ “ ฉันจะทดสอบอีกครั้งเมื่อฉันทำเสร็จแล้ว” และผู้มีส่วนได้ส่วนเสียคิดในแง่ของ “ ถ้าเขียนชิ้นนั้นไปแล้วทำไมฉันต้องสอบซ้ำ”
ในฐานะคนที่อยู่ในทั้งสองด้านของสเปกตรัมการพัฒนาฉันได้พูดทั้งสองสิ่งนี้ นักพัฒนาในตัวฉันรู้ดีว่าทำไมเราถึงต้องทดสอบใหม่
การเปลี่ยนแปลงที่เราทำในแต่ละวันอาจส่งผลกระทบอย่างมาก ตัวอย่างเช่น:
- สวิตช์ของคุณบัญชีถูกต้องสำหรับค่าใหม่ที่คุณใส่หรือไม่?
- คุณรู้หรือไม่ว่าคุณใช้สวิตช์นั้นกี่ครั้ง?
- คุณพิจารณาการเปรียบเทียบสตริงที่ไม่คำนึงถึงตัวพิมพ์เล็กและใหญ่อย่างถูกต้องหรือไม่
- คุณกำลังตรวจสอบค่าว่างอย่างเหมาะสมหรือไม่?
- ข้อยกเว้นการโยนได้รับการจัดการตามที่คุณคาดไว้หรือไม่?
การทดสอบหน่วยใช้คำถามเหล่านี้และจดจำไว้ในรหัสและก กระบวนการ เพื่อให้แน่ใจว่าคำถามเหล่านี้จะได้รับคำตอบเสมอ สามารถทำการทดสอบหน่วยก่อนสร้างเพื่อให้แน่ใจว่าคุณไม่ได้นำเสนอข้อบกพร่องใหม่ ๆ เนื่องจากการทดสอบหน่วยได้รับการออกแบบให้เป็นแบบปรมาณูจึงทำงานได้เร็วมากโดยปกติจะใช้เวลาน้อยกว่า 10 มิลลิวินาทีต่อการทดสอบ แม้ในแอปพลิเคชันขนาดใหญ่มากชุดทดสอบเต็มรูปแบบสามารถดำเนินการได้ภายในไม่ถึงชั่วโมง กระบวนการ UAT ของคุณตรงกับสิ่งนั้นหรือไม่?
Fibonacci_GetNthTerm_Input2_AssertResult1 ซึ่งเป็นการรันครั้งแรกและรวมเวลาในการตั้งค่าการทดสอบหน่วยทั้งหมดจะใช้เวลาไม่เกิน 5 มิลลิวินาที หลักการตั้งชื่อของฉันที่นี่ถูกตั้งขึ้นเพื่อให้ค้นหาคลาสหรือวิธีการภายในคลาสที่ฉันต้องการทดสอบได้อย่างง่ายดาย
ในฐานะนักพัฒนาบางทีนี่อาจดูเหมือนว่าจะได้ผลมากกว่าสำหรับคุณ ใช่คุณสบายใจได้ว่ารหัสที่คุณปล่อยนั้นดี แต่การทดสอบหน่วยยังเปิดโอกาสให้คุณเห็นว่าการออกแบบของคุณอ่อนแอ คุณกำลังเขียนการทดสอบหน่วยเดียวกันสำหรับรหัสสองชิ้นหรือไม่? พวกเขาควรอยู่ในโค้ดชิ้นเดียวแทนหรือไม่?
รับไฟล์ รหัสที่จะทดสอบหน่วยได้ เป็นวิธีที่คุณสามารถปรับปรุงการออกแบบของคุณ และสำหรับนักพัฒนาซอฟต์แวร์ส่วนใหญ่ที่ไม่เคยทดสอบหน่วยหรือใช้เวลาพิจารณาการออกแบบก่อนเขียนโค้ดไม่มากนักคุณจะรู้ได้ว่าการออกแบบของคุณดีขึ้นมากเพียงใดโดยเตรียมให้พร้อมสำหรับการทดสอบหน่วย
หน่วยรหัสของคุณทดสอบได้หรือไม่?
นอกจากดรายแล้วเรายังมีข้อควรพิจารณาอื่น ๆ
วิธีการหรือหน้าที่ของคุณพยายามทำมากเกินไปหรือไม่?
หากคุณจำเป็นต้องเขียนการทดสอบหน่วยที่ซับซ้อนเกินไปซึ่งใช้เวลานานกว่าที่คุณคาดไว้วิธีการของคุณอาจซับซ้อนเกินไปและเหมาะสมกว่าเมื่อใช้หลายวิธี
คุณใช้ประโยชน์จาก Dependency Injection อย่างเหมาะสมหรือไม่?
หากวิธีการทดสอบของคุณต้องการคลาสหรือฟังก์ชันอื่นเราเรียกสิ่งนี้ว่าการพึ่งพา ในการทดสอบหน่วยเราไม่สนใจว่าการพึ่งพากำลังทำอะไรอยู่ภายใต้ประทุน สำหรับวัตถุประสงค์ของวิธีการภายใต้การทดสอบจะเป็นกล่องดำ การพึ่งพามีชุดการทดสอบหน่วยของตัวเองซึ่งจะตัดสินว่าพฤติกรรมของมันทำงานอย่างถูกต้องหรือไม่
ในฐานะผู้ทดสอบคุณต้องการจำลองการอ้างอิงนั้นและบอกค่าที่จะส่งคืนในอินสแตนซ์เฉพาะ วิธีนี้จะช่วยให้คุณสามารถควบคุมกรณีทดสอบของคุณได้ดีขึ้น ในการดำเนินการนี้คุณจะต้องฉีดเวอร์ชันจำลอง (หรือที่เราจะเห็นในภายหลังล้อเลียน) ของการอ้างอิงนั้น
ส่วนประกอบของคุณโต้ตอบซึ่งกันและกันอย่างที่คุณคาดหวังหรือไม่?
เมื่อคุณได้พิจารณาการอ้างอิงและการเพิ่มการพึ่งพาของคุณแล้วคุณอาจพบว่าคุณได้แนะนำการอ้างอิงแบบวงจรในรหัสของคุณ ถ้าคลาส A ขึ้นอยู่กับคลาส B ซึ่งขึ้นอยู่กับคลาส A คุณควรพิจารณาการออกแบบของคุณใหม่
ความงามของการฉีดพึ่งพิง
ลองพิจารณาของเรา ตัวอย่าง Fibonacci . เจ้านายของคุณบอกคุณว่าพวกเขามีคลาสใหม่ที่มีประสิทธิภาพและแม่นยำกว่าตัวดำเนินการเพิ่มปัจจุบันที่มีอยู่ใน C #
แม้ว่าตัวอย่างนี้จะไม่มีโอกาสมากนักในโลกแห่งความเป็นจริง แต่เราเห็นตัวอย่างที่คล้ายคลึงกันในส่วนประกอบอื่น ๆ เช่นการตรวจสอบสิทธิ์การแมปวัตถุและกระบวนการอัลกอริทึมใด ๆ สำหรับจุดประสงค์ของบทความนี้ลองแกล้งทำเป็นว่าฟังก์ชันการเพิ่มใหม่ของลูกค้าของคุณเป็นฟังก์ชันล่าสุดและดีที่สุดนับตั้งแต่มีการคิดค้นคอมพิวเตอร์
ด้วยเหตุนี้เจ้านายของคุณจึงมอบคลังกล่องดำที่มีคลาสเดียว Math และในคลาสนั้นฟังก์ชันเดียว Add งานของคุณในการใช้เครื่องคำนวณ Fibonacci มีแนวโน้มที่จะมีลักษณะดังนี้:
public int GetNthTerm(int n) { Math math = new Math(); int nMinusTwoTerm = 1; int nMinusOneTerm = 1; int newTerm = 0; for (int i = 2; i นี่ไม่ใช่เรื่องน่ากลัว คุณสร้างอินสแตนซ์ใหม่ Math คลาสและใช้เพื่อเพิ่มสองคำก่อนหน้าเพื่อรับคำถัดไป คุณเรียกใช้วิธีนี้ผ่านการทดสอบแบตเตอรี่ตามปกติโดยคำนวณได้ถึง 100 เทอมคำนวณระยะที่ 1,000 เทอมที่ 10,000 และอื่น ๆ จนกว่าคุณจะรู้สึกพอใจว่าวิธีการของคุณทำงานได้ดี บางครั้งในอนาคตผู้ใช้บ่นว่าคำที่ 501 ไม่ทำงานตามที่คาดไว้ คุณใช้เวลาช่วงเย็นในการดูโค้ดของคุณและพยายามหาสาเหตุที่ทำให้กรณีมุมนี้ไม่ทำงาน คุณเริ่มสงสัยว่า Math ล่าสุดและยิ่งใหญ่ที่สุด ชั้นเรียนไม่ค่อยดีเท่าที่เจ้านายของคุณคิด แต่มันเป็นกล่องดำและคุณพิสูจน์ไม่ได้จริงๆว่า - คุณถึงจุดอับจนภายใน
ปัญหาที่นี่คือการพึ่งพา Math ไม่ได้ฉีดเข้าไปในเครื่องคำนวณ Fibonacci ของคุณ ดังนั้นในการทดสอบของคุณคุณมักจะพึ่งพาผลลัพธ์ที่มีอยู่ยังไม่ผ่านการทดสอบและไม่รู้จักจาก Math เพื่อทดสอบ Fibonacci กับ. หากมีปัญหากับ Math Fibonacci จะผิดเสมอ (โดยไม่ต้องเข้ารหัสกรณีพิเศษสำหรับคำที่ 501st)
แนวคิดในการแก้ไขปัญหานี้คือการฉีด Math เรียนเป็นเครื่องคิดเลข Fibonacci ของคุณ แต่ที่ดีกว่านั้นคือการสร้างอินเทอร์เฟซสำหรับ Math คลาสที่กำหนดวิธีการสาธารณะ (ในกรณีของเราคือ Add) และใช้อินเทอร์เฟซบน Math ของเรา ชั้นเรียน.
public interface IMath { int Add(int x, int y); } public class Math : IMath { public int Add(int x, int y) { //super secret implementation here } } } แทนที่จะฉีด Math ลงใน Fibonacci เราสามารถฉีด IMath อินเทอร์เฟซเข้าสู่ Fibonacci ข้อดีคือเราสามารถกำหนด OurMath ของเราเองได้ ชั้นเรียนที่เรารู้ว่าแม่นยำและทดสอบเครื่องคิดเลขของเราเทียบกับสิ่งนั้น ยิ่งไปกว่านั้นการใช้ Moq เราสามารถกำหนดสิ่งที่ Math.Add ได้ ผลตอบแทน เราสามารถกำหนดจำนวนรวมหรือเราสามารถบอก Math.Add เพื่อคืนค่า x + y
private IMath _math; public Fibonacci(IMath math) { _math = math; } ใส่อินเทอร์เฟซ IMath ลงในคลาส Fibonacci
//setup Mock mockMath = new Mock(); mockMath .Setup(r => r.Add(It.IsAny(), It.IsAny())) .Returns((int x, int y) => x + y); ใช้ Moq เพื่อกำหนดอะไร Math.Add ผลตอบแทน
ตอนนี้เรามีวิธีการลองและเป็นจริง (ถ้าตัวดำเนินการ + นั้นผิดใน C # เราจะมีปัญหาที่ใหญ่กว่า) สำหรับการเพิ่มตัวเลขสองตัว การใช้ Mocked IMath ใหม่ของเราเราสามารถเขียนโค้ดการทดสอบหน่วยสำหรับคำที่ 501st ของเราและดูว่าเราดำเนินการติดตั้งหรือไม่หรือกำหนดเอง Math ชั้นต้องทำงานเพิ่มอีกหน่อย
อย่าปล่อยให้วิธีการพยายามทำมากเกินไป
ตัวอย่างนี้ยังชี้ให้เห็นถึงแนวคิดของวิธีการที่ทำมากเกินไป แน่นอนว่าการเพิ่มเป็นการดำเนินการที่ค่อนข้างง่ายโดยไม่จำเป็นต้องแยกฟังก์ชันการทำงานออกจาก GetNthTerm ของเรามากนัก วิธี. แต่จะเกิดอะไรขึ้นถ้าการดำเนินการซับซ้อนขึ้นเล็กน้อย? แทนที่จะเพิ่มเติมบางทีอาจเป็นการตรวจสอบโมเดลเรียกโรงงานเพื่อขอรับอ็อบเจ็กต์เพื่อดำเนินการหรือรวบรวมข้อมูลที่จำเป็นเพิ่มเติมจากที่เก็บ
นักพัฒนาส่วนใหญ่จะพยายามยึดติดกับแนวคิดของวิธีการหนึ่งที่มีจุดประสงค์เดียว ในการทดสอบหน่วยเราพยายามยึดหลักการที่ว่าการทดสอบหน่วยควรใช้กับวิธีการทางอะตอมและโดยการนำการดำเนินการมากเกินไปมาใช้กับวิธีการที่เราทำให้ไม่สามารถทดสอบได้ เรามักจะสร้างปัญหาที่เราต้องเขียนแบบทดสอบมากมายเพื่อทดสอบฟังก์ชันของเราอย่างถูกต้อง
พารามิเตอร์แต่ละตัวที่เราเพิ่มลงในเมธอดจะเพิ่มจำนวนการทดสอบที่เราต้องเขียนแบบเอ็กซ์โพเนนเชียลตามความซับซ้อนของพารามิเตอร์ หากคุณเพิ่มบูลีนลงในตรรกะของคุณคุณต้องเพิ่มจำนวนการทดสอบเป็นสองเท่าเพื่อเขียนเนื่องจากตอนนี้คุณต้องตรวจสอบกรณีจริงและเท็จพร้อมกับการทดสอบปัจจุบันของคุณ ในกรณีของการตรวจสอบโมเดลความซับซ้อนของการทดสอบหน่วยของเราสามารถเพิ่มขึ้นได้อย่างรวดเร็ว
เราทุกคนมีความผิดในการเพิ่มวิธีการเล็กน้อย แต่วิธีการที่ใหญ่และซับซ้อนมากขึ้นเหล่านี้ทำให้ต้องมีการทดสอบหน่วยมากเกินไป และจะเห็นได้ชัดอย่างรวดเร็วเมื่อคุณเขียนการทดสอบหน่วยว่าวิธีนี้พยายามทำมากเกินไป หากคุณรู้สึกว่ากำลังพยายามทดสอบผลลัพธ์ที่เป็นไปได้มากเกินไปจากพารามิเตอร์อินพุตของคุณให้พิจารณาข้อเท็จจริงที่ว่าวิธีการของคุณต้องแบ่งออกเป็นชุดย่อย ๆ
อย่าทำซ้ำตัวเอง
หนึ่งในผู้เช่าโปรแกรมที่เราชื่นชอบ อันนี้ควรจะตรงไปตรงมาพอสมควร หากคุณพบว่าตัวเองกำลังเขียนแบบทดสอบเดียวกันมากกว่าหนึ่งครั้งแสดงว่าคุณได้แนะนำโค้ดมากกว่าหนึ่งครั้ง อาจเป็นประโยชน์กับคุณในการปรับโครงสร้างใหม่ที่ทำงานในคลาสทั่วไปที่สามารถเข้าถึงได้ทั้งสองอินสแตนซ์ที่คุณพยายามใช้
มีเครื่องมือทดสอบหน่วยอะไรบ้าง?
DotNet นำเสนอแพลตฟอร์มการทดสอบหน่วยที่มีประสิทธิภาพมากนอกกรอบ เมื่อใช้สิ่งนี้คุณสามารถใช้สิ่งที่เรียกว่า จัดการ, กระทำ, ยืนยันวิธีการ . คุณจัดเตรียมการพิจารณาเบื้องต้นของคุณปฏิบัติตามเงื่อนไขเหล่านั้นด้วยวิธีการของคุณภายใต้การทดสอบจากนั้นยืนยันบางสิ่งที่เกิดขึ้น คุณสามารถยืนยันอะไรก็ได้ทำให้เครื่องมือนี้มีประสิทธิภาพมากยิ่งขึ้น คุณสามารถยืนยันได้ว่าเมธอดถูกเรียกตามจำนวนครั้งที่ระบุว่าเมธอดส่งคืนค่าเฉพาะระบุว่ามีการโยนข้อยกเว้นประเภทใดประเภทหนึ่งหรืออย่างอื่นที่คุณคิดได้ สำหรับผู้ที่มองหาเฟรมเวิร์กขั้นสูง NUnit และ Java ที่เป็นคู่กัน JUnit เป็นทางเลือกที่เป็นไปได้
[TestMethod] //Test To Verify Add Never Called on the First Term public void Fibonacci_GetNthTerm_Input0_AssertAddNeverCalled() { //Arrange int n = 0; //setup Mock mockMath = new Mock(); mockMath .Setup(r => r.Add(It.IsAny(), It.IsAny())) .Returns((int x, int y) => x + y); UnitTests.Fibonacci fibonacci = new UnitTests.Fibonacci(mockMath.Object); //Act int result = fibonacci.GetNthTerm(n); //Assert mockMath.Verify(r => r.Add(It.IsAny(), It.IsAny()), Times.Never); } การทดสอบว่าวิธีฟีโบนักชีของเราจัดการกับตัวเลขที่เป็นลบโดยทิ้งข้อยกเว้น การทดสอบหน่วยสามารถตรวจสอบได้ว่าเกิดข้อยกเว้น
เพื่อจัดการกับการฉีดแบบพึ่งพาทั้งสองอย่าง Ninject และ ความสามัคคี มีอยู่บนแพลตฟอร์ม DotNet มีความแตกต่างกันเล็กน้อยระหว่างสองอย่างนี้และกลายเป็นประเด็นว่าคุณต้องการจัดการการกำหนดค่าด้วย Fluent Syntax หรือ XML Configuration
สำหรับการจำลองการอ้างอิงขอแนะนำ Moq Moq อาจเป็นเรื่องท้าทายในการรับมือ แต่สิ่งสำคัญคือคุณสร้างการอ้างอิงของคุณในรูปแบบจำลอง จากนั้นคุณบอกการพึ่งพาว่าจะส่งคืนอะไรภายใต้เงื่อนไขเฉพาะ ตัวอย่างเช่นหากคุณมีเมธอดชื่อ Square(int x) ที่กำลังสองของจำนวนเต็มคุณสามารถบอกได้เมื่อ x = 2 ส่งกลับ 4 คุณสามารถบอกให้ส่งคืน x ^ 2 สำหรับจำนวนเต็มใดก็ได้ หรือคุณบอกให้ส่งกลับ 5 เมื่อ x = 2 ทำไมคุณถึงทำกรณีสุดท้าย? ในกรณีที่วิธีการภายใต้บทบาทของการทดสอบคือการตรวจสอบคำตอบจากการอ้างอิงคุณอาจต้องการบังคับให้ตอบกลับคำตอบที่ไม่ถูกต้องเพื่อให้แน่ใจว่าคุณตรวจจับข้อบกพร่องได้อย่างถูกต้อง
[TestMethod] //Test To Verify Add Called Three times on the fifth Term public void Fibonacci_GetNthTerm_Input4_AssertAddCalledThreeTimes() { //Arrange int n = 4; //setup Mock mockMath = new Mock(); mockMath .Setup(r => r.Add(It.IsAny(), It.IsAny())) .Returns((int x, int y) => x + y); UnitTests.Fibonacci fibonacci = new UnitTests.Fibonacci(mockMath.Object); //Act int result = fibonacci.GetNthTerm(n); //Assert mockMath.Verify(r => r.Add(It.IsAny(), It.IsAny()), Times.Exactly(3)); } ใช้ Moq เพื่อบอกคนที่ล้อเลียน IMath อินเตอร์เฟซวิธีจัดการ Add อยู่ระหว่างการทดสอบ คุณสามารถตั้งค่ากรณีที่ไม่เหมาะสมได้ด้วย It.Is หรือช่วงที่มี It.IsInRange.
กรอบการทดสอบหน่วยสำหรับ DotNet
Microsoft Unit Testing Framework
Microsoft Unit Testing Framework เป็นโซลูชันการทดสอบหน่วยแบบสำเร็จรูปจาก Microsoft และรวมอยู่ใน Visual Studio เนื่องจากมาพร้อมกับ VS จึงรวมเข้ากับมันได้ดี เมื่อคุณเริ่มโครงการ Visual Studio จะถามคุณว่าคุณต้องการสร้างไลบรารีการทดสอบหน่วยที่ด้านข้างของแอปพลิเคชันของคุณหรือไม่
Microsoft Unit Testing Framework ยังมาพร้อมกับเครื่องมือมากมายที่จะช่วยให้คุณวิเคราะห์ขั้นตอนการทดสอบของคุณได้ดีขึ้น นอกจากนี้เนื่องจาก Microsoft เป็นเจ้าของและเขียนขึ้นจึงมีความรู้สึกมั่นคงในการดำรงอยู่ในอนาคต
แต่เมื่อทำงานกับเครื่องมือของ Microsoft คุณจะได้รับสิ่งที่มอบให้คุณ Microsoft Unit Testing Framework อาจยุ่งยากในการรวมเข้าด้วยกัน
NUnit
กลับหัวที่ใหญ่ที่สุดสำหรับฉันในการใช้ NUnit คือการทดสอบแบบกำหนดพารามิเตอร์ ในตัวอย่าง Fibonacci ข้างต้นเราสามารถป้อนกรณีทดสอบต่างๆและตรวจสอบให้แน่ใจว่าผลลัพธ์เหล่านั้นเป็นจริง และในกรณีของปัญหา 501st ของเราเราสามารถเพิ่มชุดพารามิเตอร์ใหม่ได้เสมอเพื่อให้แน่ใจว่าการทดสอบจะทำงานอยู่เสมอโดยไม่ต้องใช้วิธีการทดสอบใหม่
ข้อเสียเปรียบที่สำคัญของ NUnit คือการรวมเข้ากับ Visual Studio ไม่มีเสียงระฆังและนกหวีดที่มาพร้อมกับเวอร์ชัน Microsoft และหมายความว่าคุณจะต้องดาวน์โหลดชุดเครื่องมือของคุณเอง
xUnit.Net
xUnit ได้รับความนิยมอย่างมากใน C # เพราะมันรวมเข้ากับระบบนิเวศ. NET ที่มีอยู่ได้เป็นอย่างดี Nuget มีส่วนขยายของ xUnit มากมาย นอกจากนี้ยังทำงานร่วมกับ Team Foundation Server ได้เป็นอย่างดีแม้ว่าฉันจะไม่แน่ใจว่ามีจำนวนเท่าใด นักพัฒนา. NET ยังคงใช้ TFS กับการใช้งาน Git ต่างๆ
ในทางกลับกันผู้ใช้หลายคนบ่นว่าเอกสารของ xUnit ขาดไปเล็กน้อย สำหรับผู้ใช้ใหม่ในการทดสอบหน่วยอาจทำให้ปวดหัวมาก นอกจากนี้ความสามารถในการขยายและความสามารถในการปรับตัวของ xUnit ยังทำให้เส้นการเรียนรู้มีความเข้มข้นกว่า NUnit หรือ Microsoft’s Unit Testing Framework
ทดสอบการออกแบบ / การพัฒนาแบบขับเคลื่อน
การออกแบบ / พัฒนาแบบทดสอบขับเคลื่อน (TDD) เป็นหัวข้อขั้นสูงที่ควรค่าแก่การโพสต์ของตนเอง อย่างไรก็ตามฉันต้องการให้ข้อมูลเบื้องต้น
แนวคิดคือเริ่มต้นด้วยการทดสอบหน่วยของคุณและบอกการทดสอบหน่วยของคุณว่าอะไรถูกต้อง จากนั้นคุณสามารถเขียนโค้ดของคุณเกี่ยวกับการทดสอบเหล่านั้น ตามทฤษฎีแล้วแนวคิดนี้ฟังดูเรียบง่าย แต่ในทางปฏิบัติเป็นการยากมากที่จะฝึกสมองให้คิดย้อนกลับเกี่ยวกับแอปพลิเคชัน แต่วิธีนี้มีประโยชน์ในตัวคือไม่จำเป็นต้องเขียนการทดสอบหน่วยของคุณหลังจากข้อเท็จจริง สิ่งนี้นำไปสู่การปรับโครงสร้างใหม่การเขียนซ้ำและความสับสนในชั้นเรียนน้อยลง
TDD เป็นคำที่แพร่หลายในช่วงไม่กี่ปีที่ผ่านมา แต่การนำมาใช้นั้นช้า ลักษณะแนวความคิดสร้างความสับสนให้กับผู้มีส่วนได้ส่วนเสียซึ่งทำให้ยากที่จะได้รับการอนุมัติ แต่ในฐานะนักพัฒนาขอแนะนำให้คุณเขียนแม้แต่แอปพลิเคชันขนาดเล็กโดยใช้แนวทาง TDD เพื่อให้คุ้นเคยกับกระบวนการนี้
ทำไมคุณไม่สามารถทดสอบหน่วยได้มากเกินไป
การทดสอบหน่วยเป็นหนึ่งในเครื่องมือทดสอบที่ทรงพลังที่สุดที่นักพัฒนามีให้เลือกใช้ ไม่มีวิธีใดเพียงพอสำหรับการทดสอบแอปพลิเคชันของคุณอย่างสมบูรณ์ แต่ประโยชน์ในการทดสอบการถดถอยการออกแบบโค้ดและเอกสารวัตถุประสงค์นั้นไม่ตรงกัน
ไม่มีสิ่งที่เรียกว่าการเขียนแบบทดสอบหน่วยมากเกินไป ขอบแต่ละกรณีสามารถเสนอปัญหาขนาดใหญ่ในซอฟต์แวร์ของคุณ การระลึกถึงจุดบกพร่องที่พบขณะทดสอบหน่วยจะช่วยให้แน่ใจว่าข้อบกพร่องเหล่านั้นไม่พบวิธีที่จะเล็ดลอดกลับเข้าสู่ซอฟต์แวร์ของคุณในระหว่างการเปลี่ยนแปลงโค้ดในภายหลัง แม้ว่าคุณอาจเพิ่ม 10-20% ในงบประมาณล่วงหน้าของโครงการ แต่คุณสามารถประหยัดได้มากกว่านั้นในการฝึกอบรมการแก้ไขข้อบกพร่องและการจัดทำเอกสาร
คุณสามารถค้นหาที่เก็บ Bitbucket ที่ใช้ในบทความนี้ ที่นี่ .
ทำความเข้าใจพื้นฐาน
การทดสอบหน่วยหมายความว่าอย่างไร
หน่วยทดสอบกระบวนการทดสอบแต่ละวิธี การทดสอบหน่วยช่วยให้มั่นใจได้ว่าส่วนประกอบแต่ละชิ้นทำหน้าที่ได้ตามวัตถุประสงค์
ตัวอย่างการทดสอบหน่วยคืออะไร?
หน่วยการทดสอบกระบวนการทดสอบฟังก์ชันอะตอมโดยการส่งผ่านค่าที่ทราบไปยังฟังก์ชันนั้นและยืนยันผลลัพธ์ที่คาดว่าจะได้รับจากฟังก์ชัน
การทดสอบหน่วยดำเนินการอย่างไร?
การทดสอบหน่วยดำเนินการโดยใช้กรอบงานและชุดเครื่องมือซึ่งมักจะปรับให้เหมาะกับกรอบงานฐานรหัสของคุณ
การทดสอบหน่วยที่ดีคืออะไร?
การทดสอบหน่วยที่ดีคือการรวมอินพุตที่เป็นไปได้ทั้งหมดลงในวิธีการของคุณ ผู้ออกแบบควรทราบผลลัพธ์ของวิธีการเหล่านี้และการทดสอบหน่วยควรสะท้อนถึงผลลัพธ์ที่คาดหวัง
การทดสอบหน่วยมีประโยชน์อย่างไร?
การทดสอบหน่วยช่วยให้มั่นใจในคุณภาพของโค้ดของคุณโดยกำหนดให้คุณต้องเขียนโค้ดที่ทดสอบได้ซึ่งจะช่วยให้มั่นใจได้ถึงการทำงานของโค้ดของคุณและเป็นจุดเริ่มต้นที่ดีเยี่ยมสำหรับการทดสอบการถดถอย
การทดสอบหน่วยคุ้มค่าหรือไม่?
ใช่. การทดสอบหน่วยอาจเพิ่มต้นทุนการพัฒนาของคุณเล็กน้อย แต่ในระยะยาวการทดสอบจะช่วยให้คุณประหยัดเวลาและความพยายามผ่านการทดสอบการถดถอยและการระลึกถึงจุดบกพร่อง
ฉันควรเขียนแบบทดสอบกี่หน่วย?
ตามหลักการแล้วการทดสอบหน่วยของคุณควรครอบคลุมทุกแง่มุมของรหัสของคุณในทุกความเป็นไปได้ แน่นอนในความเป็นจริงนั้นเป็นไปไม่ได้และคำตอบง่ายๆคือคุณไม่สามารถเขียนแบบทดสอบหน่วยมากเกินไปได้
