การทดสอบหน่วยคืออะไร?

การทดสอบหน่วยคืออะไร?

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

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

ตัวอย่างเช่นใน Python:

def add (a, b): 
return a + b 
def test_add():
assert add(2, 3) == 5

การทดสอบง่ายๆ นี้จะตรวจสอบว่า add ฟังก์ชันนี้ส่งคืนผลลัพธ์ที่ถูกต้อง แม้จะดูไม่ซับซ้อน แต่ก็แสดงให้เห็นถึงแนวคิดที่ว่า ตรวจสอบตรรกะด้วยตนเองก่อนผสานรวมกับระบบอื่นๆ

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

คำอธิบายวิดีโอการทดสอบหน่วย

ทำไมต้องทำการทดสอบหน่วย?

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

เหตุผลสำคัญในการทำการทดสอบยูนิตในวิศวกรรมซอฟต์แวร์มีดังนี้

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

ในระยะสั้น: การทดสอบยูนิตช่วยประหยัดเวลา ลดความเสี่ยง และปรับปรุงความน่าเชื่อถือ. มันเปลี่ยนการทดสอบจากความคิดที่เจ็บปวดภายหลังให้กลายเป็นแนวปฏิบัติทางวิศวกรรมเชิงรุก

จะดำเนินการทดสอบยูนิตได้อย่างไร?

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

ขั้นตอนที่ 1) วิเคราะห์หน่วยและกำหนดกรณี

ระบุพฤติกรรมที่ทดสอบได้เล็กที่สุด รายการ เส้นทางแห่งความสุข, เคสขอบและ เงื่อนไขข้อผิดพลาด. ชี้แจงข้อมูลอินพุต/เอาต์พุต และเงื่อนไขก่อน/หลัง

ขั้นตอนที่ 2) ตั้งค่าสภาพแวดล้อมการทดสอบ

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

ขั้นตอนที่ 3) เขียนแบบทดสอบ (รูปแบบ AAA)

เตรียมการ อินพุตและบริบท → กระทำ โดยการเรียกหน่วย → ยืนยัน ผลลัพธ์ที่คาดหวัง เน้นการยืนยันพฤติกรรมมากกว่ารายละเอียดการนำไปใช้ภายใน

# Arrange
cart = Cart(tax_rate=0.1)
# Act
total = cart.total([Item("book", 100)])
# Assert
assert total == 110

ขั้นตอนที่ 4) รันในเครื่องและใน CI

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

ขั้นตอนที่ 5) วินิจฉัยความล้มเหลว แก้ไข และรีแฟกเตอร์

เมื่อการทดสอบล้มเหลว แก้ไขโค้ดหรือทดสอบไม่ใช่ทั้งสองอย่างพร้อมกัน หลังจากสีเขียว ให้รีแฟกเตอร์ด้วยความมั่นใจ—ทดสอบพฤติกรรมการ์ด

ขั้นตอนที่ 6) รันซ้ำอีกครั้ง Revอ่านและบำรุงรักษา

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

เคล็ดลับสำหรับมืออาชีพ:

• เก็บการทดสอบ รวดเร็ว (<200 มิลลิวินาทีต่ออัน) และ อิสระ.
• การทดสอบชื่อสำหรับ พฤติกรรม (เช่น, test_total_includes_tax).
• ปฏิบัติต่อความไม่เสถียรเหมือนกับจุดบกพร่อง กักกัน แก้ไขสาเหตุหลัก แล้วเปิดใช้งานอีกครั้ง

เทคนิคการทดสอบยูนิตมีอะไรบ้าง?

การทดสอบยูนิตจะมีประสิทธิผลมากที่สุดเมื่อผสมผสาน เทคนิคการออกแบบการทดสอบอย่างชาญฉลาด สีสดสวย เป้าหมายความคุ้มครองที่สมเหตุสมผลมุ่งเน้นไปที่ความกว้างในส่วนที่สำคัญ ความลึกในส่วนที่มีความเสี่ยงสูงที่สุด และต่อต้านกับดัก "100% หรือล้มเหลว"

เค้ก เทคนิคการทดสอบหน่วย แบ่งได้เป็น 3 ส่วนหลักๆ คือ

1. การทดสอบกล่องดำ ซึ่งเกี่ยวข้องกับการทดสอบอินเทอร์เฟซผู้ใช้ ร่วมกับอินพุตและเอาต์พุต
2. การทดสอบกล่องสีขาว เกี่ยวข้องกับการทดสอบพฤติกรรมการทำงานของแอปพลิเคชันซอฟต์แวร์
3. การทดสอบกล่องสีเทา ใช้ในการดำเนินการชุดทดสอบ วิธีทดสอบ และกรณีทดสอบ และดำเนินการวิเคราะห์ความเสี่ยง

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

• ความคุ้มครองคำชี้แจง
• ความคุ้มครองการตัดสินใจ
• ความคุ้มครองสาขา
• ความคุ้มครองสภาพ
• ความครอบคลุมของเครื่องจักรที่มีสถานะจำกัด

สำหรับข้อมูลเพิ่มเติมเกี่ยวกับการครอบคลุมโค้ด โปรดดู https://www.guru99.com/code-coverage.html

บทบาทของการล้อเลียนและการสตับในการทดสอบยูนิตคืออะไร

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

เหตุใดจึงต้องใช้การทดสอบ Doubles?

• ความเหงา – ทดสอบเฉพาะหน่วยเท่านั้น ไม่ใช่ฐานข้อมูล เครือข่าย หรือระบบไฟล์
• determinism – ควบคุมผลลัพธ์และผลข้างเคียงเพื่อให้ผลลัพธ์มีความสอดคล้องกัน
• ความเร็ว – การทดสอบจะทำงานภายในเวลาไม่กี่มิลลิวินาทีเมื่อไม่ได้สัมผัสกับระบบภายนอก
• การจำลองกรณีขอบ – เลียนแบบข้อผิดพลาด (เช่น API หมดเวลา) ได้อย่างง่ายดายโดยไม่ต้องรอในชีวิตจริง

ไม่สมบูรณ์

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

ตัวอย่าง (Python):

def get_user_from_db(user_id):
# Imagine a real DB call here
raise NotImplementedError()
def test_returns_user_with_stub(monkeypatch):
# Arrange: stubbed DB call
monkeypatch.setattr("app.get_user_from_db", lambda _: {"id": 1, "name": "Alice"})
# Act
user = get_user_from_db(1)
# Assert
assert user["name"] == "Alice"

เยาะเย้ย

A เยาะเย้ย มีประสิทธิภาพมากกว่า: สามารถตรวจสอบการโต้ตอบได้ (เช่น "วิธีนี้ถูกเรียกใช้ด้วย X หรือไม่")

ตัวอย่าง (Javaสคริปต์พร้อมมุขตลก):

const sendEmail = jest.fn();
function registerUser(user, emailService) {
emailService(user.email, "Welcome!");
test("sends welcome email", () => {
// Arrange
const user = { email: "test@example.com" };
// Act
registerUser(user, sendEmail);
// Assert
expect(sendEmail).toHaveBeenCalledWith("test@example.com", "Welcome!");

});

ที่นี่ เยาะเย้ย ตรวจสอบว่าบริการอีเมลถูกเรียกใช้งานอย่างถูกต้อง ซึ่งเป็นสิ่งที่สตับทำไม่ได้

ข้อผิดพลาดทั่วไป

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

กฎของหัวแม่มือ

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

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

เครื่องมือทดสอบยูนิตทั่วไปมีอะไรบ้าง

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

1. JUnit:Junit เป็นเครื่องมือทดสอบที่ใช้งานได้ฟรีสำหรับ Java ภาษาโปรแกรม มีการยืนยันเพื่อระบุวิธีการทดสอบ เครื่องมือนี้จะทดสอบข้อมูลก่อน แล้วจึงแทรกข้อมูลลงในโค้ด
2. หน่วย:NUnit เป็นเฟรมเวิร์กการทดสอบยูนิตที่ใช้กันอย่างแพร่หลายสำหรับภาษา .NET ทุกภาษา เป็นเครื่องมือโอเพนซอร์สที่ช่วยให้สามารถเขียนสคริปต์ด้วยตนเองได้ รองรับการทดสอบที่ขับเคลื่อนด้วยข้อมูล ซึ่งสามารถทำงานแบบขนานได้
3. PHPUnit:PHPUnit เป็นเครื่องมือทดสอบยูนิตสำหรับโปรแกรมเมอร์ PHP โปรแกรมนี้ใช้โค้ดส่วนเล็กๆ ที่เรียกว่ายูนิต แล้วทดสอบแต่ละส่วนแยกกัน เครื่องมือนี้ยังช่วยให้นักพัฒนาสามารถใช้เมธอดการยืนยันที่กำหนดไว้ล่วงหน้าเพื่อยืนยันว่าระบบทำงานในลักษณะที่กำหนด

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

การพัฒนาการทดสอบการขับเคลื่อน (TDD) และการทดสอบหน่วย

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

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

ประโยชน์บางประการของ TDD มีดังนี้:

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

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

เหตุใดจึงต้องรวมการทดสอบยูนิตเข้ากับ CI/CD?

การทดสอบยูนิตจะมอบคุณค่าสูงสุดเมื่อเชื่อมต่อโดยตรงเข้ากับ การรวมอย่างต่อเนื่องและไปป์ไลน์การส่งมอบอย่างต่อเนื่อง (CI/CD). แทนที่จะเป็นเพียงความคิดภายหลัง กลับกลายเป็น ประตูคุณภาพ ที่ตรวจสอบการเปลี่ยนแปลงทุกอย่างโดยอัตโนมัติก่อนที่จะจัดส่ง

ต่อไปนี้คือเหตุผลในการรวมการทดสอบยูนิตเข้าในกระบวนการ CI/CD:

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

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

ต่อไปนี้คือความเข้าใจผิดทั่วไปบางประการเกี่ยวกับการทดสอบยูนิต:

“มันต้องใช้เวลา และฉันก็มักจะมีตารางงานแน่นเอี๊ยดเสมอ โค้ดของฉันแน่นมาก! ฉันไม่จำเป็นต้องทดสอบยูนิตเลย”

ตำนานโดยธรรมชาติแล้วถือเป็นสมมติฐานที่ผิด สมมติฐานเหล่านี้นำไปสู่วงจรอุบาทว์ดังนี้ –

ความจริงก็คือการทดสอบยูนิตจะช่วยเพิ่มความเร็วในการพัฒนา

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

ข้อได้เปรียบในการทดสอบหน่วย

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

ข้อเสียการทดสอบหน่วย

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

ขอแนะนำให้ใช้การทดสอบยูนิตร่วมกับกิจกรรมการทดสอบอื่น

แนวทางปฏิบัติที่ดีที่สุดในการทดสอบหน่วย

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

คำถามที่พบบ่อย

สรุป