nose vs pytest - อะไรคือความแตกต่าง (ส่วนตัว) ที่ควรทำให้ฉันเลือก [ปิด]


85

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

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

ฉันได้ดูเอกสารของทั้ง nose และ pytest เล็กน้อยและเท่าที่ฉันเห็นส่วนที่ใหญ่กว่าของไลบรารีเหล่านั้นสนับสนุนฟังก์ชันการทำงานเดียวกันเป็นหลักยกเว้นว่าอาจมีชื่อแตกต่างกันหรือต้องการไวยากรณ์ที่แตกต่างกันเล็กน้อย นอกจากนี้ฉันสังเกตเห็นความแตกต่างเล็กน้อยในปลั๊กอินที่มีอยู่ (จมูกมีการสนับสนุนหลายกระบวนการเช่น pytest ดูเหมือนจะไม่)

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

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


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

9
pytestไม่รองรับการสนับสนุนหลายกระบวนการผ่านปลั๊กอินpytest-xdist
Bruno Oliveira

2
นอกจากนี้ผู้จัดการบริบทเป็นเพียงวัตถุ Python ธรรมดาและคุณสามารถเรียกใช้manager.__enter__()ในของคุณTestCase.setUp()และmanager.__exit__()ในtearDown()ไฟล์.
rescdsk

3
จมูกจะไม่ถูกเก็บรักษาไว้
toasted_flakes

คำตอบ:


80

ฉันเคยใช้ Nose เพราะเป็นค่าเริ่มต้นของ Pylons ฉันไม่ชอบมันเลย มันมีเส้นเอ็นการกำหนดค่าในหลาย ๆ ที่แทบทุกอย่างดูเหมือนจะทำด้วยปลั๊กอินที่ไม่ได้รับเอกสารซึ่งทำให้มันเกิดความสับสนและอ้อมมากขึ้นและเนื่องจากมันทำการทดสอบโดยไม่ได้ตั้งใจโดยค่าเริ่มต้นมันจึงทำลาย Unicode tracebacks เป็นประจำโดยซ่อนแหล่งที่มาของข้อผิดพลาด

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

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


2
ปัญหาบางอย่างเกี่ยวกับการซ่อนการย้อนกลับได้รับการแก้ไขเกี่ยวกับจมูก 0.11 เมื่อหลายปีก่อน เนื่องจากพอร์ต Python 3 ฉันคาดว่าการย้อนกลับของ Unicode จะมีน้อยลง (แม้ว่าโดยส่วนตัวฉันคิดว่าฉันพบปัญหา Unicode ที่มีจมูกเพียงครั้งเดียวซึ่งจะครอบตัดเมื่อรวมเข้ากับคลาสฐานกรณีทดสอบบางตัวที่ทำ "เคล็ดลับ" บางอย่างที่ไม่ได้ ' ไม่สมเหตุสมผลจริงๆ - นั่นไม่ใช่ความผิดของจมูก) ฉันสงสัยว่าในความเป็นจริงเครื่องมือทั้งสองมีขอบขรุขระหลุดออกมาในช่วงหลายปีที่ผ่านมาดังนั้นบางทีคุณอาจจะชอบสิ่งที่ดีที่สุดที่คุณใช้ล่าสุด ;-)
Croad Langshan

สิ่งที่เกี่ยวกับส่วนเอกสารล่าสุด ฉันยังสับสนว่าจะใช้ nosetests หรือ py.test ทั้งสองอย่างดูเหมือนจะดีพอ ๆ กัน แต่จากที่ฉันอ่านพบว่าผู้คนส่วนใหญ่ใช้การทดสอบจมูกในปัจจุบัน อะไรคือสาเหตุเมื่อ py.tests มีชุดของไลบรารีการประมวลผลหลายตัวที่ดีกว่า
proprius

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

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