ฉันจะทดสอบรหัสทดสอบได้อย่างไร


22

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

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

สำหรับฉันดูเหมือนว่าวิธีที่ดีที่สุดในการทำเช่นนี้คือเพื่อให้แน่ใจว่าการทดสอบล้มเหลวสำหรับรหัสบั๊กกี้ * ถ้าฉันใช้เวลา 2 นาทีสลับกันเพิ่มข้อผิดพลาดในรหัสและทำให้แน่ใจว่าล้มเหลวฉันควรมีความมั่นใจในระดับที่ยอมรับได้ว่า การทดสอบ 'ทำงาน' สิ่งนี้นำมาสู่คำถามที่สองของฉัน: อะไรคือวิธีที่ดีในการแนะนำข้อบกพร่องเพื่อให้แน่ใจว่าพวกเขาถูกจับในกรณีทดสอบ? ฉันควรสุ่มแสดงความคิดเห็นงบตรวจสอบให้แน่ใจว่าสาขาที่ไม่ถูกต้องของการif-elseเรียกใช้โดยปฏิเสธสภาพของมันและเปลี่ยนลำดับการดำเนินการของรหัสที่มีผลข้างเคียง ฯลฯ จนกว่าฉันจะพอใจการทดสอบของฉันจะจับมากที่สุดโรคจิตที่พบบ่อย? นักพัฒนามืออาชีพตรวจสอบว่าการทดสอบทำในสิ่งที่ควรทำอย่างไร พวกเขาแค่คิดว่าการทดสอบทำงานหรือพวกเขาใช้เวลาในการทดสอบเช่นกัน? ถ้าเป็นเช่นนั้นพวกเขาจะทำการทดสอบอย่างไร

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

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


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

เป็นไปได้ซ้ำของ วิธีการทดสอบการทดสอบ?
ริ้น

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

คำตอบ:


16

โฟลว์มาตรฐานสำหรับ TDD คือ:

  1. เขียนการทดสอบที่ล้มเหลว (สีแดง)
  2. ทำการเปลี่ยนแปลงรหัสที่เล็กที่สุดที่ทำให้ผ่าน (สีเขียว)
  3. Refactor (ทำให้เป็นสีเขียว)

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

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

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


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

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

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

@Andy: ระมัดระวังที่จะอธิบายว่านี่คือการใช้งานที่สมบูรณ์แบบเมื่อฉันมีข้อผิดพลาดทั้งในรหัสและในการทดสอบและอย่างใดอย่างหนึ่งทำให้ฉันจากการสังเกตอื่น ๆ ? (ข้อผิดพลาดในรหัสคือรายการที่ว่างเปล่าจะถูกส่งกลับและข้อผิดพลาดในการทดสอบคือการที่ฉันตรวจสอบnullและไม่ว่างเปล่า)
Christian Hackl

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

9

วิธีหนึ่งคือการทดสอบการกลายพันธุ์โดยใช้เครื่องมืออย่างJester :

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


4

ทดสอบเพื่อทดสอบ? อย่าไปทางนั้น ถ้าอย่างนั้นคุณอาจจะต้องทำการทดสอบเพื่อทำการทดสอบและจากนั้นทำการทดสอบเพื่อทำการทดสอบสำหรับการทดสอบ ... คุณหยุดที่ไหน?

ขั้นตอนการทดสอบตามปกติจะเป็นเช่นนี้และในฐานะนักพัฒนาคุณจะใช้เวลาส่วนใหญ่ในคะแนน 1-3:

  1. รหัส
  2. การทดสอบหน่วย
  3. การทดสอบบูรณาการ
  4. ระบบ / อัตโนมัติอื่น ๆ
  5. QA / ผู้ทดสอบมนุษย์

ถ้าฉันใช้เวลา 2 นาทีสลับกันเพิ่มข้อบกพร่องในรหัส (... )

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

ฉันควรสุ่มแสดงความคิดเห็นงบตรวจสอบให้แน่ใจว่าสาขาที่ไม่ถูกต้องของ if-else ได้รับการดำเนินการโดยปฏิเสธเงื่อนไข (... )

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

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


3
ฉันไม่กังวลเกี่ยวกับรหัสของฉันที่เพิ่มขึ้นข้อบกพร่องของตัวเองฉันกังวลเกี่ยวกับการทดสอบของฉันจับพวกเขาเมื่อพวกเขาเกิดขึ้น หากการทดสอบของฉันมีข้อผิดพลาดพวกเขาจะไม่ทำงานและฉันจะคิดว่าฉันได้กำจัดข้อผิดพลาดบางประเภทเมื่อพวกเขายังคงมีอยู่จริงเพียงแค่ทำให้งานของฉันยากขึ้นเพราะฉันกำลังดูผลการทดสอบที่ไม่ถูกต้อง (ผ่านเมื่อพวกเขาควรจะล้มเหลว)
Gordon Gustafson

@CrazyJugglerDrummer: การทดสอบของคุณจะไม่จับข้อบกพร่องทั้งหมดที่แน่นอน พวกเขาไม่ได้ให้บริการตามวัตถุประสงค์ - นี่คือที่ QA เข้ามาถ้าพวกเขาจะทำมันก็หมายความว่าซอฟต์แวร์ปราศจากข้อผิดพลาดเว้นแต่การเปลี่ยนแปลงซอร์สโค้ดซึ่งฉันไม่เคยเห็นมาก่อน
กม.

3

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


0

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

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


-2

มีการทดสอบการกลายพันธุ์ที่ประเมินและวัดความเหมาะสมและคุณภาพของการทดสอบ

เราสามารถใช้สิ่งนี้เพื่อประเมิน "การทดสอบ" เอง

โดยย่อเราสามารถประเมินผลการทดสอบของเรา (เช่น TestA) โดยการทดสอบ TestA สามารถค้นหาความแตกต่างระหว่างรหัสและรหัสการกลายพันธุ์ (คล้ายกันมาก แต่แตกต่างกันเล็กน้อยกับรหัสต้นฉบับ)

หาก TestA ไม่สามารถค้นหาความแตกต่างระหว่างรหัสและรหัสการกลายพันธุ์ของมันหมายความว่า TestA มีกฎระเบียบที่หยาบเกินไปที่จะทดสอบรหัสต้นฉบับ

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