การครอบคลุมโค้ด 100% เป็นความฝันที่ไพเราะหรือไม่?

28

มันเป็นไปได้ที่จะคาดหวังความคุ้มครองรหัส 100% ในการใช้งานเว็บ jquery / backbonejs หนัก? มันสมเหตุสมผลที่จะล้มเหลวในการวิ่งเนื่องจากความครอบคลุม 100% ไม่พบเมื่อครอบคลุมรหัสจริงวนเวียนอยู่รอบ ๆ 92% -95% ใน javascript / jquery?

code-quality tdd bdd

— willz
แหล่งที่มา

7

"ล้มเหลวในการวิ่ง" ฟังดูเป็นลางไม่ดีอย่างน่าประหลาด…

— Donal Fellows

5

มันเป็นเส้นกำกับ

— Robert Harvey

12

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

— ratchet freak

11

อะไรก็เกิดขึ้นได้. คำถามจริงคือมูลค่าของรหัสครอบคลุม 100% คุ้มค่ากับเวลาและทรัพยากรหรือไม่

— JohnFx

5

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

— Mason Wheeler

30

มันเป็นจริงอย่างเท่าเทียมกันตามที่ไม่สมจริง

สมจริง
หากคุณมีการทดสอบอัตโนมัติที่แสดงให้เห็นว่าครอบคลุมทั้งรหัสทั้งหมดการยืนยันเมื่อครอบคลุม 100% นั้นสมเหตุสมผล
นอกจากนี้ยังขึ้นอยู่กับความสำคัญของโครงการ ยิ่งสำคัญยิ่งจำเป็นต้องคาดหวัง / ต้องการการครอบคลุมโค้ดที่สมบูรณ์ยิ่งขึ้น
การทำเช่นนี้ง่ายขึ้นสำหรับโครงการขนาดเล็กถึงขนาดกลาง

ไม่สมจริง
คุณจะเริ่มต้นที่ความครอบคลุม 0% ...
โครงการนี้มีความผิดพลาดมากมายหลายเส้นทางที่มีข้อผิดพลาดมากมายที่ยากต่อการสร้างหรือทริกเกอร์
ผู้บริหารไม่เต็มใจที่จะกระทำ / ลงทุนเพื่อให้แน่ใจว่ามีความครอบคลุม

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

เราไม่ทราบถึงผลกระทบของความล้มเหลวในโครงการของคุณดังนั้นเราจึงไม่สามารถพูดได้ว่า 92% หรือ 95% ก็เพียงพอแล้วหรือถ้าจำเป็น 100% หรือสำหรับเรื่องนั้น 100% จะทดสอบทุกอย่างที่คุณคาดหวัง

30

... และเพียงเพราะคุณมีรหัสครอบคลุม 100% ไม่ได้หมายความว่าคุณมีสาขาครอบคลุม 100% ดังนั้นแม้ว่าจะมีรหัสครอบคลุม 100% คุณก็อาจพลาดได้มากมาย

— ไบรอัน Oakley

3

+1 สำหรับขนาดโครงการ การแบ่งองค์ประกอบที่เล็กกว่าสามารถใช้ซ้ำได้และทดสอบได้ทำให้เราได้รับความคุ้มครองถึง 95% ไม่จำเป็นต้องครอบคลุม 100% การทดสอบการรวมควรครอบคลุมช่องว่างการทดสอบหน่วย

— Apoorv Khurasia

5

@BryanOakley ... และการทดสอบของคุณอาจไม่มีจุดหมายหรือแม้แต่ทดสอบอะไรก็ได้

— David_001

5

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

— Izkata

4

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

— Andrea

32

ใครเป็นคนทดสอบการทดสอบ?

มันไร้เดียงสาที่ดีที่สุดและไม่สมจริงแม้ในแง่ทฤษฎีและทำไม่ได้ในแง่ธุรกิจ

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

การทดสอบโค้ดทุกบรรทัดไม่ใช่เป้าหมายที่ดี

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

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

ปัญหาการหยุดชะงัก:

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

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

เนื่องจากคุณไม่สามารถพิสูจน์สิ่งที่ใช้งานได้ 100% เหตุใดจึงตั้งเป้าหมายของคุณ

ธรรมดาและเรียบง่ายในกรณีส่วนใหญ่มันไม่สมเหตุสมผลเลย

7

นี่ต้องเป็นคำตอบที่ได้รับการยอมรับจริงๆ การครอบคลุมโค้ด 100% นั้นแย่มากถึง 0%

— Ryathal

1

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

— still_dreaming_1

2

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

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

— Predrag Stojadinović

17

ในกรณีส่วนใหญ่การครอบคลุมโค้ด 100% หมายความว่าคุณได้ "โกง" เล็กน้อย:

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

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

— แดนโมเนโก
แหล่งที่มา

การย้ายสิ่งของไปสู่การโกง DSL เป็นอย่างไร

— back2dos

2

@ back2dos - ในขณะที่คุณอาจทดสอบหน่วยบอกว่าสคริปต์หลามฝังตัวของคุณคุณอาจไม่ได้ทดสอบหน่วยแม่แบบ html ของคุณหรือ CSS ของคุณหรือนับบรรทัดในพวกเขาไปสู่การประมาณการครอบคลุม

— Dan Monego

12

สำหรับที่น่าประทับใจเช่นโลกแห่งความจริงของสาขาครอบคลุม 100%ดูวิธี SQLite ผ่านการทดสอบ

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

— ไบรอัน Oakley
แหล่งที่มา

9

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

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

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

— bwalk2895
แหล่งที่มา

1

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

— Donal Fellows

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

— Peter Smith

สิ่งนี้ conflates unit testingกับintegration testingรหัสการทดสอบที่คุณไม่ได้เขียนคือintegrationการทดสอบ สแต็ก TCP อยู่ในระบบปฏิบัติการที่คุณไม่ควรทำการทดสอบคุณควรถือว่ามันถูกทดสอบแล้วโดยผู้ที่เคยเขียน

4

ฉันจะบอกว่าถ้ารหัสถูกออกแบบมาโดยมีเป้าหมายเฉพาะเพื่อให้ครอบคลุมการทดสอบ 100% แต่ 100% อาจไม่สามารถทำได้ เหตุผลข้อหนึ่งก็คือหากคุณใช้รหัสป้องกัน - ซึ่งคุณควร - บางครั้งคุณควรมีรหัสที่จัดการกับสถานการณ์ที่คุณแน่ใจว่าไม่ควรเกิดขึ้นหรือไม่สามารถเกิดขึ้นได้หากคุณมีความรู้เกี่ยวกับระบบ เพื่อครอบคลุมรหัสดังกล่าวด้วยการทดสอบจะยากมากตามคำนิยาม หากไม่มีรหัสดังกล่าวอาจเป็นอันตราย - จะเกิดอะไรขึ้นถ้าคุณทำผิดและสถานการณ์เช่นนี้จะเกิดขึ้นเพียงครั้งเดียวจาก 256 ครั้ง? เกิดอะไรขึ้นถ้ามีการเปลี่ยนแปลงในสถานที่ที่ไม่เกี่ยวข้องซึ่งทำให้สิ่งที่เป็นไปไม่ได้? ฯลฯ ดังนั้น 100% อาจเข้าถึงได้ยากโดยวิธี "ธรรมชาติ" - เช่นถ้าคุณมีรหัสที่จัดสรรหน่วยความจำและคุณมีรหัสที่ตรวจสอบว่ามันล้มเหลวเว้นแต่คุณจำลองผู้จัดการหน่วยความจำออก (ซึ่งอาจไม่ใช่เรื่องง่าย) และเขียนการทดสอบที่ส่งคืน "หน่วยความจำไม่เพียงพอ" ซึ่งครอบคลุมรหัสนั้นอาจเป็นเรื่องยาก สำหรับแอปพลิเคชัน JS อาจเป็นการป้องกันการเข้ารหัสรอบ ๆ DOM ที่เป็นไปได้ของนิสัยใจคอในเบราว์เซอร์ที่แตกต่างกันความล้มเหลวของบริการภายนอกเป็นต้น

ดังนั้นฉันจะบอกว่าหนึ่งควรพยายามที่จะใกล้เคียงกับ 100% ที่เป็นไปได้และมีเหตุผลที่ดีสำหรับเดลต้า แต่ฉันจะไม่เห็นไม่ได้รับ 100% อย่างแน่นอนว่าเป็นความล้มเหลว 95% สามารถปรับได้ในโครงการขนาดใหญ่ขึ้นอยู่กับ 5%

— StasM
แหล่งที่มา

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

— still_dreaming_1

2

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

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

หากคุณกำลังนำการทดสอบไปยังโครงการที่มีอยู่ซึ่งการทดสอบยังไม่ได้รับการบำรุงรักษาหรือรวมก่อนหน้านั้นเป็นไปไม่ได้ที่จะได้รับการครอบคลุมโค้ด 100% โดยไม่มีค่าใช้จ่ายในการฝึกเมื่อเทียบกับความพยายาม สิ่งที่ดีที่สุดที่คุณสามารถคาดหวังได้คือการให้ความคุ้มครองการทดสอบสำหรับส่วนที่สำคัญของรหัสที่เรียกว่ามากที่สุด

มันสมเหตุสมผลที่จะล้มเหลวในการวิ่งเนื่องจากความครอบคลุม 100% ไม่พบเมื่อครอบคลุมรหัสจริงวนเวียนอยู่รอบ ๆ 92% -95% ใน javascript / jquery?

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

— S.Robins
แหล่งที่มา

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

— still_dreaming_1

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

— S.Robins

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

— still_dreaming_1

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

— still_dreaming_1

1

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

มีอุปสรรคบางอย่างที่คุณพบที่ป้องกันไม่ให้คุณกดปุ่มสองสามบรรทัดสุดท้ายหรือไม่? ถ้าไม่ถ้าได้รับความคุ้มครองจาก 95% ถึง 100% นั้นตรงไปตรงมาดังนั้นคุณอาจไปทำเช่นนั้น เนื่องจากคุณที่นี่ถามว่าฉันจะคิดว่ามีเป็นบางสิ่งบางอย่าง อะไรคือสิ่งที่?

— mjfgates
แหล่งที่มา

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

— still_dreaming_1

0

92% ไม่เป็นไร ฉันรู้สึกว่าคำถามที่แท้จริงคือ:

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

— Michael Durrant
แหล่งที่มา

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

— still_dreaming_1

0

Martin Fowler เขียนในบล็อกของเขา :I would be suspicious of anything like 100% - it would smell of someone writing tests to make the coverage numbers happy, but not thinking about what they are doing.

อย่างไรก็ตามยังมีมาตรฐานที่ให้ความคุ้มครอง 100% ในระดับหน่วย ตัวอย่างเช่นมันเป็นหนึ่งในข้อกำหนดในมาตรฐานของชุมชน spaceflight ยุโรป (ECSS, ความร่วมมือยุโรปเพื่อการมาตรฐานอวกาศ) กระดาษที่เชื่อมโยงที่นี่บอกเล่าเรื่องราวที่น่าสนใจของโครงการที่มีเป้าหมายในการเข้าถึงการทดสอบ 100% ในซอฟต์แวร์ที่เสร็จสมบูรณ์แล้ว มันขึ้นอยู่กับ nterviews กับวิศวกรที่เกี่ยวข้องที่พัฒนาหน่วยทดสอบ

บทเรียนบางส่วน ได้แก่ :

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

— user6681109
แหล่งที่มา

0

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

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

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

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

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

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

นี่คือความพยายามสองสามอย่างที่จะทำให้การเข้ารหัสเป็นธรรมชาติมากขึ้น:

https://github.com/jcoplien/trygve

https://github.com/still-dreaming-1/PurposefulPhp

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

— still_dreaming_1
แหล่งที่มา

-2

การเข้าถึงโค้ดใหม่ 100% นั้นสามารถทำได้จริงมากและถ้าคุณฝึก TDD คุณอาจจะโดนมันโดยปริยายเพราะคุณตั้งใจที่จะเขียนแบบทดสอบสำหรับรหัสการผลิตทุกบรรทัด

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

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

หนังสือของ Michael Feather " การทำงานอย่างมีประสิทธิภาพด้วยรหัสมรดก " เป็นสิ่งที่มีค่าสำหรับเราในการหากลยุทธ์ในการเพิ่มการทดสอบในรหัสเดิมของเรา

— ริชาร์ดเวลส์
แหล่งที่มา

-3

ไม่เป็นไปไม่ได้และไม่เคยเป็น ถ้าเป็นไปได้คณิตศาสตร์ทั้งหมดก็จะตกอยู่ในขั้นตอนสุดท้าย ตัวอย่างเช่นคุณจะทดสอบฟังก์ชันที่ใช้จำนวนเต็ม 64 บิตสองตัวและคูณได้อย่างไร นี่เป็นปัญหาของฉันเสมอกับการทดสอบกับการพิสูจน์ว่าโปรแกรมถูกต้อง สำหรับทุกอย่างยกเว้นโปรแกรมที่น่ารำคาญที่สุดการทดสอบนั้นไม่มีประโยชน์เพราะมันครอบคลุมเฉพาะบางกรณีเท่านั้น มันเหมือนกับการตรวจสอบตัวเลข 1,000 ตัวและบอกว่าคุณได้พิสูจน์การคาดเดาของ Goldbach แล้ว

— veryfoolish
แหล่งที่มา

Oh! ดังนั้นบางคนก็อารมณ์เสียที่ฉันไม่ได้ตอบปัญหาบนระนาบความคิด การทดสอบเป็นเรื่องเสีย ... มันจะไม่ทำงาน มันไม่สามารถ นักวิทยาศาสตร์คอมพิวเตอร์ที่ฉลาดที่สุดได้รู้จักสิ่งนี้ (Dijkstra, Knuth, Hoare et al.) ฉันเดาว่าคุณเป็นนักเขียนโปรแกรมจาวาสคริปต์จู่ๆการเขียนโปรแกรม eXtreme แล้วคุณไม่สนเรื่องข้อเหวี่ยงเหล่านั้น Blah อะไรก็ตามที่ใส่ใจ ... เขียนรหัสเส็งเคร็ง เสีย CO ^ 2 ในการทดสอบของคุณ - ฉันหมายถึงใครมีเวลานั่งและคิดอีกต่อไป เราได้ส่งออกไปยังคอมพิวเตอร์แล้ว

— โง่มาก

3

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

— Lunivore