คำถามติดแท็ก assertions

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

51 testing  unit-testing  assertions 

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

38 exceptions  assertions 

ฉันเป็นแฟนตัวยงของการassertตรวจสอบการเขียนในรหัส C ++ เป็นวิธีการตรวจสอบกรณีในระหว่างการพัฒนาที่ไม่สามารถเกิดขึ้นได้ แต่จะเกิดขึ้นเพราะข้อบกพร่องตรรกะในโปรแกรมของฉัน เป็นการปฏิบัติที่ดีโดยทั่วไป อย่างไรก็ตามฉันสังเกตเห็นว่าบางฟังก์ชั่นที่ฉันเขียน (ซึ่งเป็นส่วนหนึ่งของคลาสที่ซับซ้อน) มีการยืนยันมากกว่า 5+ ครั้งซึ่งรู้สึกว่ามันอาจเป็นการฝึกเขียนโปรแกรมที่ไม่ดีในแง่ของความสามารถในการอ่านและการบำรุงรักษา ฉันคิดว่ามันยังยอดเยี่ยมเพราะแต่ละคนต้องการให้ฉันคิดเกี่ยวกับฟังก์ชั่นก่อนและหลังการทำงานและพวกเขาช่วยดักจับแมลง อย่างไรก็ตามฉันแค่อยากจะเอามันออกไปถามว่ามีกระบวนทัศน์ที่ดีกว่าสำหรับการจับข้อผิดพลาดทางตรรกะในกรณีที่จำเป็นต้องใช้เช็คจำนวนมากหรือไม่ ความเห็นของ Emacs : เนื่องจาก Emacs เป็นตัวเลือกของฉันฉันจึงขอแสดงความคิดเห็นเล็กน้อยซึ่งช่วยลดความรู้สึกรกรุงรังที่พวกเขาสามารถให้ได้ นี่คือสิ่งที่ฉันเพิ่มลงในไฟล์. emacs ของฉัน: ; gray out the "assert(...)" wrapper (add-hook 'c-mode-common-hook (lambda () (font-lock-add-keywords nil '(("\\<\\(assert\(.*\);\\)" 1 '(:foreground "#444444") t))))) ; gray out the stuff inside parenthesis with a slightly lighter …

33 c++  debugging  error-handling  assertions 

ฉันเพิ่งเจอรหัสที่เพิ่งเขียนใหม่ซึ่งมีจำนวน Debug.Assert (C #) มากมาย เราควรใช้สิ่งนี้อย่างกว้างขวางแม้ว่าจะใช้ TDD, BDD และการทดสอบหน่วยโดยทั่วไปหรือไม่?

23 unit-testing  assertions 

พฤติกรรมเริ่มต้นของassertใน C ++ คือการไม่ทำอะไรเลยใน build build ฉันเข้าใจว่ามันทำด้วยเหตุผลด้านประสิทธิภาพและอาจป้องกันไม่ให้ผู้ใช้เห็นข้อความแสดงข้อผิดพลาดที่น่ารังเกียจ อย่างไรก็ตามฉันขอยืนยันว่าสถานการณ์เหล่านั้นที่assertมีผู้ถูกไล่ออก แต่ถูกปิดการใช้งานมีปัญหามากขึ้นเพราะแอปพลิเคชันอาจจะล้มเหลวในทางที่แย่ลงกว่าเดิมเพราะค่าคงที่บางส่วนถูกทำลาย นอกจากนี้อาร์กิวเมนต์ประสิทธิภาพสำหรับฉันนับเฉพาะเมื่อมันเป็นปัญหาที่วัดได้ ส่วนใหญ่assertในรหัสของฉันไม่ซับซ้อนกว่า assert(ptr != nullptr); ซึ่งจะมีผลกระทบเล็กน้อยกับรหัสส่วนใหญ่ สิ่งนี้นำไปสู่คำถาม: ควรยืนยัน (หมายถึงแนวคิดไม่ใช่การนำไปปฏิบัติเฉพาะ) ควรมีการใช้งานใน build build หรือไม่? ทำไมจะไม่ล่ะ)? โปรดทราบว่าคำถามนี้ไม่ได้เกี่ยวกับวิธีเปิดใช้งาน asserts ใน build builds (เช่น#undef _NDEBUGหรือใช้การยืนยัน assert แบบกำหนดเอง) นอกจากนี้มันไม่เกี่ยวกับการเปิดใช้งาน asserts ในรหัสห้องสมุดของบุคคลที่สาม / มาตรฐาน แต่ในรหัสที่ควบคุมโดยฉัน

20 c++  release  assertions 

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

19 testing  code-quality  tdd  code-smell  assertions 

ตกลงหรือไม่ที่จะเพิ่มการยืนยันที่ถูกเลื่อนออกไปเช่นนี้ var actualKittens = actualKittens.Select(kitten => { Assert.IsСute(kitten); return kitten }); ทำไม? ดังนั้นฉันสามารถทำซ้ำได้เพียงครั้งเดียวแม้จะมีข้อความที่คาดว่าจะเกิดการรวบรวมที่เป็นรูปธรรมเช่น: CollectionAssert.AreEquivalent(expectedKittens, actualKittens.ToList()); และมันอาจจะไม่ใช่แค่เลือก แต่เป็นวิธีที่กำหนดตัววนซ้ำและมีการตรวจสอบและตรรกะจำนวนมาก (เช่นการนับและการกรอง) สิ่งที่สงสัยคือความซับซ้อนของการอ่านและการดีบักรหัสดังกล่าวในกรณีที่การทดสอบล้มเหลว

18 c#  unit-testing  linq  iterator  assertions 

เมื่อเร็ว ๆ นี้ฉันพยายามดิ้นรนที่จะเข้าใจว่าการตรวจสอบในปริมาณที่เหมาะสมคืออะไรและวิธีการที่เหมาะสมคืออะไร ฉันมีคำถามสองสามข้อเกี่ยวกับเรื่องนี้: เป็นวิธีที่เหมาะสมในการตรวจสอบข้อผิดพลาด (อินพุตไม่ดี, รัฐไม่ดี ฯลฯ ) คืออะไร? เป็นการดีกว่าที่จะตรวจสอบข้อผิดพลาดอย่างชัดเจนหรือใช้ฟังก์ชั่นเช่นการยืนยันที่สามารถปรับให้เหมาะสมกับโค้ดสุดท้ายของคุณ? ฉันรู้สึกเหมือนกำลังตรวจสอบโปรแกรมอย่างชัดเจนด้วยรหัสพิเศษจำนวนมากซึ่งไม่ควรถูกเรียกใช้ในสถานการณ์ส่วนใหญ่อย่างไรก็ตาม - และไม่พูดถึงข้อผิดพลาดส่วนใหญ่ที่จบลงด้วยความล้มเหลวในการยกเลิก / ออก เหตุใดจึงมีฟังก์ชั่นตรวจสอบอย่างชัดเจนว่าจะยกเลิกหรือไม่ ฉันได้มองหา asserts เทียบกับการตรวจสอบข้อผิดพลาดอย่างชัดเจนและพบว่ามีเพียงเล็กน้อยที่จะอธิบายอย่างแท้จริงเมื่อต้องทำเช่นกัน ส่วนใหญ่พูดว่า 'ใช้ข้อความยืนยันเพื่อตรวจสอบข้อผิดพลาดเชิงตรรกะและใช้การตรวจสอบอย่างชัดเจนเพื่อตรวจสอบความผิดพลาดอื่น ๆ ' ดูเหมือนว่าจะไม่ได้รับเราไปไกลมาก เราจะพูดว่าเป็นไปได้หรือไม่: Malloc returning null, check explictly API user inserting odd input for functions, use asserts สิ่งนี้จะทำให้ฉันดีขึ้นเมื่อตรวจสอบข้อผิดพลาดหรือไม่ ฉันจะทำอะไรได้อีก ฉันต้องการปรับปรุงและเขียนรหัส 'มืออาชีพ' ให้ดีขึ้น

13 c  testing  assertions 

ฉันกำลังเขียนสคริปต์ที่ทำบางสิ่งบางอย่างกับไฟล์ข้อความ (สิ่งที่ไม่เกี่ยวข้องกับคำถามของฉัน) ดังนั้นก่อนที่ฉันจะทำบางสิ่งกับไฟล์ฉันต้องการตรวจสอบว่ามีไฟล์อยู่หรือไม่ ฉันสามารถทำสิ่งนี้ได้โดยไม่มีปัญหา แต่ปัญหาคือความสวยงาม นี่คือรหัสของฉันใช้สิ่งเดียวกันในสองวิธีที่แตกต่างกัน def modify_file(filename): assert os.path.isfile(filename), 'file does NOT exist.' Traceback (most recent call last): File "clean_files.py", line 15, in <module> print(clean_file('tes3t.txt')) File "clean_files.py", line 8, in clean_file assert os.path.isfile(filename), 'file does NOT exist.' AssertionError: file does NOT exist. หรือ: def modify_file(filename): if not os.path.isfile(filename): return …

12 python  error-handling  error-messages  assertions 

เกี่ยวกับการพิมพ์เป็ด : การพิมพ์เป็ดนั้นได้รับความช่วยเหลือจากการไม่ได้ทดสอบประเภทของข้อโต้แย้งในวิธีการและร่างกายโดยอาศัยเอกสารประกอบรหัสที่ชัดเจนและการทดสอบเพื่อให้แน่ใจว่าการใช้งานถูกต้อง เกี่ยวกับการตรวจสอบข้อโต้แย้ง (EAFP: ง่ายกว่าที่จะขอการอภัยมากกว่าการอนุญาต) ตัวอย่างที่ดัดแปลงจากที่นี่ : ... มันเป็นสิ่งที่ต้องทำยิ่งกว่า: def my_method(self, key): try: value = self.a_dict[member] except TypeError: # do something else ซึ่งหมายความว่าทุกคนที่ใช้รหัสของคุณไม่จำเป็นต้องใช้พจนานุกรมจริงหรือคลาสย่อย - พวกเขาสามารถใช้วัตถุใด ๆ ที่ใช้อินเทอร์เฟซการแมป น่าเสียดายในทางปฏิบัติมันไม่ง่ายอย่างนั้น ถ้าสมาชิกในตัวอย่างด้านบนอาจเป็นจำนวนเต็ม จำนวนเต็มไม่เปลี่ยนรูปดังนั้นจึงเหมาะสมอย่างยิ่งที่จะใช้เป็นคีย์พจนานุกรม อย่างไรก็ตามพวกมันยังใช้เพื่อจัดทำดัชนีวัตถุประเภทลำดับ หากสมาชิกเกิดขึ้นเป็นจำนวนเต็มตัวอย่างที่สองสามารถผ่านรายการและสตริงเช่นเดียวกับพจนานุกรม เกี่ยวกับการเขียนโปรแกรมที่แน่วแน่ : การยืนยันเป็นวิธีที่เป็นระบบในการตรวจสอบว่าสถานะภายในของโปรแกรมเป็นไปตามที่โปรแกรมเมอร์คาดไว้โดยมีเป้าหมายในการจับข้อบกพร่อง โดยเฉพาะอย่างยิ่งพวกเขาดีสำหรับการจับสมมติฐานที่ผิดพลาดที่เกิดขึ้นในขณะที่เขียนรหัสหรือใช้อินเทอร์เฟซโดยโปรแกรมเมอร์อื่น นอกจากนี้พวกเขาสามารถทำหน้าที่เป็นเอกสารในบรรทัดบางส่วนโดยทำให้สมมติฐานของโปรแกรมเมอร์ชัดเจน ("ชัดเจนดีกว่าโดยนัย") แนวคิดที่กล่าวถึงบางครั้งมีข้อขัดแย้งดังนั้นฉันจึงพิจารณาปัจจัยต่อไปนี้เมื่อเลือกว่าฉันไม่ได้ทำการตรวจสอบความถูกต้องของข้อมูลเลยให้ทำการตรวจสอบความถูกต้องอย่างแรงหรือใช้การยืนยัน: การตรวจสอบที่แข็งแกร่ง โดยการตรวจสอบที่แข็งแกร่งฉันหมายถึงการเพิ่มข้อยกเว้นที่กำหนดเอง ( ApiErrorตัวอย่าง) หากฟังก์ชัน / เมธอดของฉันเป็นส่วนหนึ่งของ API สาธารณะจะเป็นการดีกว่าถ้าตรวจสอบอาร์กิวเมนต์เพื่อแสดงข้อความแสดงข้อผิดพลาดที่ดีเกี่ยวกับประเภทที่ไม่คาดคิด โดยการตรวจสอบประเภทที่ฉันไม่ได้หมายถึงการใช้เพียงอย่างเดียวisinstanceแต่ยังถ้าวัตถุผ่านการสนับสนุนอินเทอร์เฟซที่จำเป็น …

10 python  validation  assertions  duck-typing 

ฉันเป็นแฟนตัวยงของการเขียนข้อตกลงสัญญาหรือเช็คประเภทใดก็ได้ที่มีในภาษาที่ฉันใช้ สิ่งหนึ่งที่ทำให้ฉันรำคาญใจเล็กน้อยคือฉันไม่แน่ใจว่าการปฏิบัติทั่วไปสำหรับการตรวจสอบซ้ำซ้อนคืออะไร สถานการณ์ตัวอย่าง: ฉันเขียนฟังก์ชันต่อไปนี้ก่อน void DoSomething( object obj ) { Contract.Requires<ArgumentNullException>( obj != null ); //code using obj } หลังจากนั้นไม่กี่ชั่วโมงฉันก็เขียนฟังก์ชั่นอื่นที่เรียกอันแรก เนื่องจากทุกสิ่งยังคงสดในหน่วยความจำฉันตัดสินใจที่จะไม่ทำสัญญาซ้ำเนื่องจากฉันรู้ว่าจะDoSomethingตรวจสอบวัตถุที่มีค่าว่างอยู่แล้ว: void DoSomethingElse( object obj ) { //no Requires here: DoSomething will do that already DoSomething( obj ); //code using obj } ปัญหาที่ชัดเจน: DoSomethingElseตอนนี้ขึ้นอยู่กับDoSomethingการตรวจสอบว่า obj ไม่เป็นโมฆะ ดังนั้นควรDoSomethingตัดสินใจว่าจะไม่ตรวจสอบอีกต่อไปหรือถ้าฉันตัดสินใจใช้ฟังก์ชันอื่น obj อาจไม่ได้รับการตรวจสอบอีกต่อไป ซึ่งทำให้ฉันเขียนการใช้งานนี้หลังจากทั้งหมด: …

10 assertions  code-contracts