การทดสอบ TDD ควรละเอียดมากแค่ไหน?


18

ในระหว่างการฝึกอบรม TDD ตามกรณีซอฟต์แวร์ทางการแพทย์เรากำลังใช้เรื่องต่อไปนี้: "เมื่อผู้ใช้กดปุ่มบันทึกระบบควรเพิ่มผู้ป่วยเพิ่มอุปกรณ์และเพิ่มบันทึกข้อมูลอุปกรณ์"

การใช้งานขั้นสุดท้ายจะมีลักษณะดังนี้:

if (_importDialog.Show() == ImportDialogResult.SaveButtonIsPressed)
{
   AddPatient();
   AddDevice();
   AddDeviceDataRecords();
}

เรามีสองวิธีในการติดตั้ง:

  1. การทดสอบสามครั้งที่แต่ละวิธีตรวจสอบหนึ่งวิธี (AddPatient, AddDevice, AddDeviceDataRecords) ถูกเรียก
  2. หนึ่งการทดสอบที่ตรวจสอบทั้งสามวิธีถูกเรียก

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

คำตอบ:


8

แต่ในกรณีที่สองหากการทดสอบล้มเหลวเราไม่แน่ใจว่ามีอะไรผิดปกติ

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

ในทางปฏิบัติตัวเลือกระหว่างตัวเลือก 1 และ 2 ยังขึ้นอยู่กับสถานการณ์ด้วย หากฉันเห็นรหัสที่คุณแสดงด้านบนในโครงการดั้งเดิมฉันเลือกวิธีปฏิบัติของ Case # 2 เพียงเพื่อตรวจสอบว่าวิธีการทั้ง 3 วิธีนั้นถูกเรียกอย่างถูกต้องเมื่อเงื่อนไขเป็นจริง ถ้าฉันกำลังพัฒนาโค้ดส่วนนี้ในตอนนี้การเรียกเมธอดทั้ง 3 วิธีน่าจะถูกเพิ่มทีละจุดโดยแยกกัน (อาจเป็นวันหรือเป็นเดือนห่างกัน) ดังนั้นฉันจะเพิ่มการทดสอบหน่วยใหม่แยกต่างหาก เพื่อตรวจสอบการโทรแต่ละครั้ง

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


คุณไม่คิดว่ามันจะสมเหตุสมผลหรือไม่ที่จะรวมการทดสอบทั้งสามเข้าด้วยกันในที่สุด?
SiberianGuy

@Idsa อาจเป็นการตัดสินใจที่สมเหตุสมผลแม้ว่าในทางปฏิบัติแล้วฉันไม่ค่อยใส่ใจกับการปรับโครงสร้างเช่นนี้ จากนั้นอีกครั้งฉันกำลังทำงานกับรหัสดั้งเดิมที่มีความสำคัญแตกต่างกัน: เรามุ่งเน้นที่การเพิ่มความครอบคลุมการทดสอบของรหัสที่มีอยู่และรักษาจำนวนการทดสอบหน่วยที่เพิ่มขึ้นได้
PéterTörök

30

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

unittest ทดสอบฟังก์ชันการทำงานหนึ่งหน่วยโดยมีการพึ่งพาน้อยที่สุดเท่าที่จะทำได้ ในกรณีของคุณมี 4 unittests

  • AddPatient เพิ่มผู้ป่วย (เช่นเรียกใช้ฟังก์ชันฐานข้อมูลที่เกี่ยวข้อง) หรือไม่
  • AddDevice เพิ่มอุปกรณ์หรือไม่
  • AddDeviceDataRecords เพิ่มระเบียนหรือไม่
  • ฟังก์ชันหลัก unamend ในตัวอย่างของคุณโทร AddPatient, AddDevice และ AddDeviceFunctions

Unittests สำหรับนักพัฒนาเพื่อให้พวกเขามั่นใจได้ว่ารหัสของพวกเขาถูกต้องทางเทคนิค

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

เมื่อผู้ใช้ป้อนข้อมูลให้คลิกตกลงและ ...

  • ... ไปที่รายการผู้ป่วยเขาควรเห็นผู้ป่วยรายใหม่ที่มีชื่อที่ให้ไว้
  • ... ไปที่รายการอุปกรณ์เขาควรเห็นอุปกรณ์ใหม่
  • ... ไปที่รายละเอียดของอุปกรณ์ใหม่เขาควรเห็นดาต้าแคร์ใหม่

การทดสอบการยอมรับสำหรับลูกค้าหรือเพื่อสร้างการสื่อสารที่ดีขึ้นกับพวกเขา

ในการตอบคำถามของคุณ "สิ่งที่คุณต้องการ": ปัญหาที่ใหญ่กว่าสำหรับคุณในขณะนี้คืออะไรข้อบกพร่องและการถดถอย (=> unittests เพิ่มเติม) หรือความเข้าใจและทำให้ภาพรวมเป็นใหญ่ (=> การทดสอบการยอมรับมากขึ้น)


13

เรามีสองวิธีในการติดตั้ง:

นั่นเป็นเท็จ

การทดสอบสามครั้งที่แต่ละวิธีตรวจสอบหนึ่งวิธี (AddPatient, AddDevice, AddDeviceDataRecords) ถูกเรียก

คุณต้องทำสิ่งนี้เพื่อให้แน่ใจว่ามันใช้งานได้

หนึ่งการทดสอบที่ตรวจสอบทั้งสามวิธีถูกเรียก

คุณต้องยังทำเช่นนี้เพื่อให้แน่ใจว่าการทำงานของ API

คลาส - เป็นหน่วย - จะต้องผ่านการทดสอบอย่างสมบูรณ์ แต่ละวิธี

คุณสามารถเริ่มต้นด้วยการทดสอบที่ครอบคลุมทั้งสามวิธี แต่ไม่ได้บอกอะไรมาก

หากการทดสอบล้มเหลวเราไม่แน่ใจว่าเกิดอะไรขึ้น

แก้ไข. นั่นเป็นเหตุผลที่คุณทดสอบวิธีการทั้งหมด

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


2

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

ตัวอย่างเช่นสมมติว่าการเพิ่มผู้ป่วยในระบบของคุณจำเป็นต้องเรียกรูทีนย่อย (ฟังก์ชั่นเด็ก) บางอย่าง:

  1. VerifyPatientQualification
  2. EnsureDoctorExistence
  3. CheckInsuranceHistory
  4. EnsureEmptyBed

เราอาจเขียนการทดสอบหน่วยสำหรับแต่ละฟังก์ชั่นเหล่านี้


2

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

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.