คำถามติดแท็ก test-coverage

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

122 unit-testing  testing  test-coverage 

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

64 testing  test-coverage 

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

59 java  unit-testing  test-coverage 

ฉันได้รับมอบหมายให้รับแอปพลิเคชันรุ่นเก่าภายใต้การทดสอบหน่วย เริ่มจากพื้นฐานเกี่ยวกับแอปพลิเคชั่น: เป็นฐานรหัส LOC Java RCP 600k ที่มีปัญหาสำคัญเหล่านี้ การทำสำเนารหัสจำนวนมาก ไม่มีการห่อหุ้มข้อมูลส่วนตัวส่วนใหญ่สามารถเข้าถึงได้จากภายนอกข้อมูลทางธุรกิจบางส่วนยังสร้างซิงเกิลตันดังนั้นจึงไม่เพียง แต่เปลี่ยนแปลงจากภายนอก แต่ยังมาจากทุกที่ ไม่มี abstractions (เช่นไม่มีโมเดลธุรกิจข้อมูลธุรกิจถูกเก็บไว้ใน Object [] และ double [] []) ดังนั้นจึงไม่มี OO มีชุดทดสอบการถดถอยที่ดีและทีมงาน QA ที่มีประสิทธิภาพคือการทดสอบและค้นหาข้อบกพร่อง ฉันรู้เทคนิคในการทดสอบจากหนังสือคลาสสิกเช่น Michael Feathers แต่มันช้าเกินไป เนื่องจากมีระบบทดสอบการถดถอยที่ใช้งานได้ฉันจึงไม่กลัวที่จะทำการปรับโครงสร้างระบบใหม่อย่างจริงจังเพื่อให้สามารถเขียนการทดสอบหน่วยได้ ฉันจะเริ่มโจมตีปัญหาเพื่อให้ได้ความครอบคลุมได้อย่างรวดเร็วดังนั้นฉันจึงสามารถแสดงความคืบหน้าต่อการจัดการ (และอันที่จริงแล้วเริ่มมีรายได้จากความปลอดภัยของการทดสอบ JUnit) ฉันไม่ต้องการใช้เครื่องมือในการสร้างชุดทดสอบการถดถอยเช่น AgitarOne เพราะการทดสอบเหล่านี้ไม่ได้ทดสอบว่ามีบางอย่างถูกต้องหรือไม่

21 object-oriented  refactoring  test-coverage  junit 

หากฉันมีรหัสบางส่วนที่มีการทดสอบครอบคลุม 80% (การทดสอบทั้งหมดผ่าน) เป็นไปได้ไหมที่จะบอกว่ามันมีคุณภาพสูงกว่ารหัสที่ไม่มีการครอบคลุมการทดสอบหรือไม่ หรือมันยุติธรรมที่จะพูดว่ามันบำรุงรักษาได้มากขึ้น?

20 code-quality  test-coverage 

ฉันสงสัยว่าการวัดการครอบคลุมโค้ดตามเงื่อนไขด้วยเครื่องมือปัจจุบันสำหรับ Java นั้นไม่ล้าสมัยหรือไม่นับตั้งแต่ Java 8 ออกมา ด้วย Java 8's OptionalและStreamเราสามารถหลีกเลี่ยงโค้ดย่อย / ลูปได้ซึ่งทำให้ง่ายต่อการได้รับความคุ้มครองตามเงื่อนไขสูงมากโดยไม่ต้องทดสอบพา ธ การประมวลผลที่เป็นไปได้ทั้งหมด ลองเปรียบเทียบโค้ด Java เก่ากับโค้ด Java 8: ก่อน Java 8: public String getName(User user) { if (user != null) { if (user.getName() != null) { return user.getName(); } } return "unknown"; } มี 3 เส้นทางการประมวลผลที่เป็นไปได้ในวิธีการข้างต้น เพื่อให้ได้ความคุ้มครองตามเงื่อนไข 100% เราจำเป็นต้องสร้างการทดสอบ …

19 java  unit-testing  test-coverage  java8 

ฉันกำลังเขียนโค้ด (เรียกซ้ำ) ที่ใช้การนำทางกราฟการขึ้นต่อกันเพื่อค้นหารอบหรือความขัดแย้งในการอ้างอิง อย่างไรก็ตามฉันไม่แน่ใจว่าจะทดสอบหน่วยนี้ได้อย่างไร ปัญหาคือหนึ่งในข้อกังวลหลักของเราคือการจัดการโค้ดบนโครงสร้างกราฟที่น่าสนใจทั้งหมดที่สามารถเกิดขึ้นได้และทำให้แน่ใจว่าโหนดทั้งหมดจะได้รับการจัดการอย่างเหมาะสม ในขณะที่โดยปกติแล้วจะครอบคลุม 100% line หรือ branch ก็เพียงพอที่จะมั่นใจได้ว่าโค้ดบางตัวทำงานได้ดี แต่ก็ให้ความรู้สึกเหมือนมี 100% path path ที่คุณยังมีข้อสงสัยอยู่ ดังนั้นวิธีการเกี่ยวกับการเลือกโครงสร้างกราฟสำหรับกรณีทดสอบมีความมั่นใจว่ารหัสของพวกเขาสามารถจัดการกับพีชคณิตที่เป็นไปได้ทั้งหมดที่คุณจะพบในข้อมูลโลกแห่งความเป็นจริง ป.ล. -ถ้ามันสำคัญขอบทั้งหมดในกราฟของฉันจะมีป้ายกำกับว่า "ต้องมี" xor "ไม่สามารถมี" และไม่มีวัฏจักรเล็กน้อยและมีเพียงขอบเดียวระหว่างสองโหนด PPS-คำสั่งปัญหาเพิ่มเติมนี้เดิมถูกโพสต์โดยผู้เขียนคำถามในความคิดเห็นด้านล่าง: For all vertices N in forest F, for all vertices M, in F, such that if there are any walks between N and M they all …

18 unit-testing  graph  test-coverage 

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

15 testing  unit-testing  integration-tests  test-coverage 

ตัวอย่างเช่นหากรหัสสร้าง int แบบสุ่มจาก 0-10 และรับสาขาที่แตกต่างกันในแต่ละผลลัพธ์หนึ่งจะออกแบบชุดทดสอบเพื่อรับประกันความครอบคลุมคำสั่ง 100% ในรหัสดังกล่าวได้อย่างไร ใน Java โค้ดอาจมีลักษณะดังนี้: int i = new Random().nextInt(10); switch(i) { //11 case statements }

15 testing  test-coverage 

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

14 testing  unit-testing  test-coverage 

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

13 acceptance-testing  test-coverage 

ตอนนี้ฉันรู้ว่าผู้คนสามารถพิจารณาคำถามนี้ซ้ำหรือถามหลายครั้งในกรณีนี้ฉันจะขอบคุณลิงก์ไปยังคำถามที่เกี่ยวข้องพร้อมคำตอบสำหรับคำถามของฉัน เมื่อเร็ว ๆ นี้ฉันไม่เห็นด้วยกับบางคนเกี่ยวกับการครอบคลุมโค้ด ฉันมีกลุ่มคนที่ต้องการให้ทีมงานของเราลดการมองการครอบคลุมโค้ดทั้งหมดโดยอ้างว่าการครอบคลุม 100% ไม่ได้หมายถึงการทดสอบคุณภาพที่ดีและรหัสคุณภาพดี ฉันสามารถผลักดันกลับได้โดยการขายอาร์กิวเมนต์ที่ Code Coverage บอกฉันว่ายังไม่ได้ทดสอบอย่างแน่นอนและช่วยให้เรามุ่งเน้นไปที่พื้นที่เหล่านั้น (ข้างต้นได้รับการกล่าวถึงในลักษณะคล้ายกันในคำถาม SO อื่น ๆ เช่นนี้ - /programming/695811/pitfalls-of-code-coverage ) ข้อโต้แย้งจากคนเหล่านี้คือ - จากนั้นทีมจะตอบสนองโดยการสร้างการทดสอบคุณภาพต่ำอย่างรวดเร็วและทำให้เสียเวลาโดยไม่เพิ่มคุณภาพที่สำคัญ ในขณะที่ผมเข้าใจมุมมองของผมกำลังมองหาวิธีที่จะทำให้เป็นกรณีที่แข็งแกร่งมากขึ้นสำหรับความคุ้มครองรหัสโดยการแนะนำเครื่องมือที่มีประสิทธิภาพมากขึ้น / (Functional, Statement,Decision, Branch, Condition, State, LCSAJ, path, jump path, entry/exit, Loop, Parameter Value etc)กรอบที่ดูแลเกณฑ์ที่ครอบคลุมมากขึ้น สิ่งที่ฉันกำลังมองหาคือข้อเสนอแนะสำหรับการรวมกันของเครื่องมือครอบคลุมรหัสและการปฏิบัติ / กระบวนการที่จะไปกับพวกเขาซึ่งสามารถช่วยฉันตอบโต้ข้อโต้แย้งดังกล่าวในขณะที่รู้สึกสะดวกสบายกับคำแนะนำของฉัน ฉันยังยินดีรับฟังความคิดเห็น / ข้อเสนอแนะใด ๆ ที่ยึดตามประสบการณ์ / ความรู้ของคุณเกี่ยวกับวิธีการโต้แย้งเช่นกันเพราะในขณะที่อัตนัยการครอบคลุมโค้ดได้ช่วยให้ทีมของฉันตระหนักถึงคุณภาพของรหัสและคุณค่าของการทดสอบมากขึ้น แก้ไข: เพื่อลดความสับสนเกี่ยวกับการเข้าใจจุดอ่อนของการครอบคลุมโค้ดทั่วไปฉันต้องการชี้ให้เห็นว่าฉันไม่ได้อ้างถึงเครื่องมือ …

11 java  unit-testing  tools  test-coverage 

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

10 unit-testing  code-quality  integration-tests  test-coverage