จะทดสอบอย่างไร?

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

ฉันสามารถคิดถึงข้อผิดพลาดสามประเภทที่เป็นไปได้ในการทดสอบ:

1. ข้อผิดพลาดเชิงตรรกะเมื่อโปรแกรมเมอร์เข้าใจผิดงานในมือและการทดสอบทำในสิ่งที่เขาคิดว่าพวกเขาควรทำซึ่งผิด

2. ข้อผิดพลาดในกรอบการทดสอบพื้นฐาน (เช่น. การเยาะเย้ยสิ่งที่เป็นนามธรรม);

3. ข้อบกพร่องในการทดสอบ: การทดสอบทำแตกต่างจากที่โปรแกรมเมอร์คิดไว้เล็กน้อย

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

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

1. มีเทคนิคบางอย่างที่ป้องกันคุณจากการเพิ่มข้อผิดพลาดเดียวกันทั้งในรหัสและการทดสอบของคุณ:

   1. ไคลเอ็นต์ควรเป็นบุคคลที่แตกต่างจากผู้ปฏิบัติ
   2. ก่อนอื่นให้เขียนการทดสอบแล้วจึงใช้รหัส

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

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

ลองทำแบบทดสอบย่อย ๆ (สั้น) เท่าที่จะทำได้

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

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

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

วิธีที่ครบถ้วนสมบูรณ์มากขึ้นในการทดสอบคุณภาพของชุดทดสอบคือการใช้การทดสอบการกลายพันธุ์

สำหรับ # 1 และ # 3: การทดสอบหน่วยไม่ควรมีตรรกะใด ๆ ถ้าคุณทำคุณอาจทดสอบมากกว่าหนึ่งสิ่งในการทดสอบหน่วยของคุณ แนวทางปฏิบัติที่ดีที่สุดสำหรับการทดสอบหน่วยคือการทดสอบหนึ่งครั้งต่อการทดสอบหนึ่งหน่วย

ดูวิดีโอนี้โดย Roy Osheroveเพื่อเรียนรู้เพิ่มเติมเกี่ยวกับวิธีการเขียนการทดสอบหน่วยดี

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

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

if (0 > printf("Hello, world\n")) {
  printf("Printing \"Hello, world\" failed\n");
}

แก้ไข: อัปเดตพร้อมคำอธิบายตามที่แนะนำโดยความคิดเห็น

เฮ้
คุณต้องสมัคร:

• ผลิตภัณฑ์ของคุณ
• การทดสอบผลิตภัณฑ์ของคุณ

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

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

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

การทดสอบกำลังตรวจสอบบางส่วนของแอปพลิเคชันเท่านั้น ฉันทดสอบแอปพลิเคชันฉันทดสอบการทดสอบ

การทดสอบไม่ควร "ฉลาด" เพียงพอที่จะใช้ดักจับข้อบกพร่อง

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

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

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

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

TL: DR: ถ้าการทดสอบของคุณต้องการการทดสอบแสดงว่าคุณทำผิด เขียนทดสอบใบ้

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

คำตอบสั้น: รหัสการผลิตการทดสอบการทดสอบ

เปรียบเทียบสิ่งนี้กับโมเดลเครดิต / เดบิตที่ใช้ในเศรษฐศาสตร์ กลไกนั้นง่ายมาก - ถ้าเครดิตแตกต่างจากเดบิตมีบางอย่างผิดปกติ

เขาไปสำหรับการทดสอบหน่วย - หากการทดสอบล้มเหลวแสดงว่ามีบางอย่างผิดปกติ อาจเป็นรหัสการผลิต แต่อาจเป็นรหัสทดสอบด้วย! ส่วนสุดท้ายนี้ถ้าสำคัญ

โปรดทราบว่าไม่สามารถพบข้อบกพร่องประเภท (1) ของคุณได้จากการทดสอบหน่วย เพื่อหลีกเลี่ยงข้อบกพร่องประเภทนี้คุณต้องใช้เครื่องมืออื่น ๆ