วิธีการเขียนการทดสอบหน่วย "ดี"?

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

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

ศิลปะการทดสอบหน่วยมีดังต่อไปนี้ที่จะพูดเกี่ยวกับการทดสอบหน่วย:

การทดสอบหน่วยควรมีคุณสมบัติดังต่อไปนี้:

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

จากนั้นต่อมาจึงเพิ่มว่าควรเป็นแบบอัตโนมัติเต็มรูปแบบเชื่อถือได้อ่านได้และบำรุงรักษาได้

ฉันขอแนะนำให้อ่านหนังสือเล่มนี้ถ้าคุณยังไม่ได้ทำ

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

การทดสอบหน่วยที่ดีไม่ได้สะท้อนฟังก์ชั่นการทดสอบ

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

กล่าวอีกนัยหนึ่งถ้าคุณพบว่าตัวเองเลียนแบบฟังก์ชั่นหลักในการทดสอบหน่วยนั่นเป็นสัญญาณที่บ่งบอกว่าคุณเสียเวลา

การทดสอบหน่วยที่ดีนั้นเป็นข้อมูลจำเพาะในรูปแบบที่รันได้:

1. อธิบายพฤติกรรมของรหัสที่สอดคล้องกับการใช้เคส
2. ครอบคลุมกรณีมุมทางเทคนิค (สิ่งที่เกิดขึ้นหากผ่านเป็นโมฆะ) - หากไม่มีการทดสอบสำหรับกรณีมุมมุมพฤติกรรมจะไม่ได้กำหนด
3. แตกถ้ารหัสทดสอบการเปลี่ยนแปลงออกไปจากสเปค

ฉันพบว่า Test-Driven-Development นั้นเหมาะสำหรับไลบรารีรูทีนเป็นอย่างมากในขณะที่คุณเขียน API ก่อนแล้วจึงนำไปใช้จริง

สำหรับ TDD ทดสอบการทดสอบ "ดี" ให้บริการที่ลูกค้าต้องการ ; ฟีเจอร์ไม่จำเป็นต้องสอดคล้องกับฟังก์ชั่นและนักพัฒนาไม่ควรสร้างสถานการณ์การทดสอบในสุญญากาศ

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

ตัวอย่างเรื่อง:

ในฐานะ [X-Wing Pilot] ฉันต้องการ [ไม่เกิน 0.0001% พอดีกับข้อผิดพลาด] เพื่อให้ [คอมพิวเตอร์เป้าหมายสามารถโจมตีพอร์ตไอเสียของ Death Star เมื่อเคลื่อนที่ด้วยความเร็วเต็มที่ผ่านหุบเขาลึก]

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

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

//Scenario 1 - can you hit the side of a barn?
Given:
    all 7 channels with no dropouts for the full half-second window,
When:
    speed is zero
    and target velocity is zero
    and all other values are constant,
Then:
    the error coefficient must be zero

//Scenario 2 - can you hit a turtle?
Given:
    all 7 channels with no dropouts for the full half-second window,
When:
    speed is zero
    and target velocity is less than c
    and all other values are constant,
Then:
    the error coefficient must be less than 0.0000000001/ns

...

//Scenario 42 - death blossom
Given:
    all 7 channels with 30% dropout and a 0.05 second sampling window
When:
    speed is zero
    and position is within enemy cluster
    and all targets are stationary
Then:
    the error coefficient must be less than 0.000001/ns for each target

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

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

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

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

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

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

ฉันพยายามทดสอบทุกอย่างทดสอบเพียงอย่างเดียว ฉันพยายามตั้งชื่อแบบทดสอบ DoDoSomething () ฉันพยายามทดสอบพฤติกรรมไม่ใช่การนำไปใช้ ฉันทดสอบวิธีสาธารณะเท่านั้น

ฉันมักจะมีหนึ่งหรือสองสามการทดสอบเพื่อความสำเร็จและอาจจะเป็นแบบทดสอบความล้มเหลวต่อวิธีการสาธารณะ

ฉันใช้จำลองมาก กรอบการจำลองที่ดีอาจเป็นประโยชน์อย่างมากเช่น PowerMock แม้ว่าฉันจะยังไม่ได้ใช้ก็ตาม

ถ้าคลาส A ใช้คลาส B อื่นฉันจะเพิ่มอินเตอร์เฟส X เพื่อให้ A ไม่ได้ใช้ B โดยตรง จากนั้นฉันก็จะสร้าง XMockup จำลองและใช้แทน B ในการทดสอบของฉัน มันช่วยเร่งการดำเนินการทดสอบลดความซับซ้อนของการทดสอบและลดจำนวนการทดสอบที่ฉันเขียนสำหรับ A เนื่องจากฉันไม่ต้องรับมือกับลักษณะเฉพาะของ B. ฉันสามารถยกตัวอย่างการทดสอบที่ A เรียก X.someMethod () แทนผลข้างเคียงของการโทร B.someMethod ()

ให้คุณทดสอบโค้ดที่สะอาดด้วยเช่นกัน

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

ฉันเห็นว่า Andry Lowry ได้โพสต์การวัดหน่วยทดสอบของ Roy Osherove แล้ว แต่ดูเหมือนว่าไม่มีใครเสนอชุด (ฟรี) ที่ลุงบ็อบมอบให้ในรหัสสะอาด (132-133) เขาใช้ตัวย่อ FIRST (นี่กับสรุปของฉัน):

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