หากคุณกำลังเขียนไลบรารีหรือแอพไฟล์ทดสอบหน่วยจะไปไหน

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

มีวิธีปฏิบัติที่ดีที่สุดที่นี่?

สำหรับไฟล์module.pyการทดสอบหน่วยควรได้รับการเรียกตามปกติตามtest_module.pyแบบแผนการตั้งชื่อของ Pythonic

มีสถานที่ที่ยอมรับกันทั่วไปหลายแห่งที่จะนำtest_module.py:

1. module.pyในไดเรกทอรีเดียวกันกับ
2. ใน../tests/test_module.py(ที่ระดับเดียวกับไดเรกทอรีรหัส)
3. ในtests/test_module.py(หนึ่งระดับภายใต้ไดเรกทอรีรหัส)

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

ไฟล์ทดสอบ 1 ไฟล์เท่านั้น

หากมีไฟล์ทดสอบเพียง 1 ไฟล์แนะนำให้วางไว้ในไดเรกทอรีระดับบนสุด:

module/
    lib/
        __init__.py
        module.py
    test.py

รันการทดสอบใน CLI

python test.py

ไฟล์ทดสอบมากมาย

หากมีไฟล์ทดสอบมากมายให้วางไว้ในtestsโฟลเดอร์:

module/
    lib/
        __init__.py
        module.py
    tests/
        test_module.py
        test_module_function.py

# test_module.py

import unittest
from lib import module

class TestModule(unittest.TestCase):
    def test_module(self):
        pass

if __name__ == '__main__':
    unittest.main()

รันการทดสอบใน CLI

# In top-level /module/ folder
python -m tests.test_module
python -m tests.test_module_function

ใช้ unittest discovery

unittest discovery จะพบการทดสอบทั้งหมดในโฟลเดอร์แพ็คเกจ

สร้าง__init__.pyในtests/โฟลเดอร์

module/
    lib/
        __init__.py
        module.py
    tests/
        __init__.py
        test_module.py
        test_module_function.py

รันการทดสอบใน CLI

# In top-level /module/ folder

# -s, --start-directory (default current directory)
# -p, --pattern (default test*.py)

python -m unittest discover

การอ้างอิง

• pytestแนวปฏิบัติที่ดีสำหรับโครงร่างการทดสอบ
• unittest

กรอบการทดสอบหน่วย

• จมูก
• nose2
• pytest

วิธีปฏิบัติทั่วไปคือการวางไดเรกทอรีการทดสอบในไดเรกทอรีหลักเดียวกันกับโมดูล / แพ็คเกจของคุณ ดังนั้นหากโมดูลของคุณถูกเรียกว่า foo.py รูปแบบไดเรกทอรีของคุณจะมีลักษณะ:

parent_dir/
  foo.py
  tests/

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

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

เรามีคำถามเดียวกันเมื่อเขียน Pythoscope ( https://pypi.org/project/pythoscope/ ) ซึ่งสร้างการทดสอบหน่วยสำหรับโปรแกรม Python เราสำรวจผู้คนในการทดสอบในรายการไพ ธ อนก่อนที่เราจะเลือกไดเรกทอรีมีความคิดเห็นที่แตกต่างกันมากมาย ในที่สุดเราเลือกที่จะวางไดเรกทอรี "การทดสอบ" ในไดเรกทอรีเดียวกันกับซอร์สโค้ด ในไดเรกทอรีนั้นเราจะสร้างไฟล์ทดสอบสำหรับแต่ละโมดูลในไดเรกทอรีหลัก

ฉันมักจะทำการทดสอบหน่วยของฉันในไฟล์ด้วยตัวเองเนื่องจาก Jeremy Cantrell อยู่เหนือบันทึกย่อแม้ว่าฉันมักจะไม่ใส่ฟังก์ชั่นการทดสอบในเนื้อหาหลัก แต่แทนที่จะใส่ทุกอย่างไว้ใน

if __name__ == '__main__':
   do tests...

บล็อก. นี่คือการเพิ่มเอกสารลงในไฟล์ในชื่อ 'โค้ดตัวอย่าง' สำหรับวิธีการใช้ไฟล์ไพ ธ อนที่คุณกำลังทดสอบ

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

if __name__ == '__main__':
   import tests.thisModule
   tests.thisModule.runtests

สิ่งนี้จะช่วยให้ใครก็ตามที่อ่านซอร์สโค้ดของคุณรู้ว่าต้องมองหาโค้ดทดสอบที่ไหน

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

เหตุผลหลักสำหรับการทำเช่นนี้คือ: refactoring refactoring

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

คำถามหลักที่คุณควรถามตัวเองคือ:

ฉันกำลังเขียน:

• ก) ห้องสมุดที่นำมาใช้ซ้ำหรือ
• b) การสร้างโครงการมากกว่าการรวมโมดูลบางส่วนเข้าด้วยกัน?

หาก:

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

แต่ก็เป็นเรื่องง่ายเหมือนกันที่จะแยกการทดสอบออกจากการแจกจ่ายเมื่อผสมกับโฟลเดอร์หลัก วางสิ่งนี้ไว้ใน setup.py :

find_packages("src", exclude=["*.tests", "*.tests.*", "tests.*", "tests"]) 

ถ้า b:

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

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

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

ฉันใช้tests/ไดเรกทอรีแล้วนำเข้าโมดูลแอปพลิเคชันหลักโดยใช้การนำเข้าแบบสัมพัทธ์ ดังนั้นใน MyApp / tests / foo.py อาจมี:

from .. import foo

เพื่อนำเข้าMyApp.fooโมดูล

ฉันไม่เชื่อว่ามี "แนวปฏิบัติที่ดีที่สุด" ที่จัดตั้งขึ้นแล้ว

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

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

                              <Main Package>
                               /          \
                              /            \
                            lib           tests
                            /                \
             [module1.py, module2.py,  [ut_module1.py, ut_module2.py,
              module3.py  module4.py,   ut_module3.py, ut_module.py]
              __init__.py]

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

ฉันแนะนำให้คุณตรวจสอบโครงการหลักของ Python บน GitHub และรับแนวคิด

เมื่อรหัสของคุณใหญ่ขึ้นและคุณเพิ่มห้องสมุดมากขึ้นจะเป็นการดีกว่าที่จะสร้างโฟลเดอร์ทดสอบในไดเรกทอรีเดียวกันกับที่คุณมี setup.py และทำมิเรอร์โครงสร้างไดเรกทอรีโครงการสำหรับการทดสอบแต่ละประเภท

ตัวอย่างเช่นถ้าคุณมีโครงสร้างไดเรกทอรีเช่น:

myPackage/
    myapp/
       moduleA/
          __init__.py
          module_A.py
       moduleB/
          __init__.py
          module_B.py
setup.py

หลังจากเพิ่มโฟลเดอร์ทดสอบคุณจะมีโครงสร้างไดเรกทอรีเช่น:

myPackage/
    myapp/
       moduleA/
          __init__.py
          module_A.py
       moduleB/
          __init__.py
          module_B.py
test/
   unit/
      myapp/
         moduleA/
            module_A_test.py
         moduleB/
            module_B_test.py
   integration/
          myapp/
             moduleA/
                module_A_test.py
             moduleB/
                module_B_test.py
setup.py

แพ็คเกจ Python ที่เขียนอย่างถูกต้องจำนวนมากใช้โครงสร้างเดียวกัน ตัวอย่างที่ดีมากคือแพ็คเกจ Boto ตรวจสอบhttps://github.com/boto/boto

ฉันจะทำอย่างไร ...

โครงสร้างโฟลเดอร์:

project/
    src/
        code.py
    tests/
    setup.py

Setup.py ชี้ไปที่ src / เป็นตำแหน่งที่มีโมดูลโครงการของฉันจากนั้นฉันเรียกใช้:

setup.py develop

ซึ่งเพิ่มโครงการของฉันลงในแพ็คเกจไซต์ชี้ไปที่สำเนาการทำงานของฉัน เพื่อรันการทดสอบของฉันฉันใช้:

setup.py tests

ใช้ตัวทดสอบที่ฉันกำหนดค่า

ฉันชอบไดเรกทอรีทดสอบระดับสูง นี่หมายถึงการนำเข้ายากขึ้นเล็กน้อย เพื่อที่ฉันมีสองวิธี:

1. ใช้ setuptools จากนั้นคุณสามารถผ่านtest_suite='tests.runalltests.suite'เข้าไปsetup()และสามารถทำการทดสอบได้อย่างง่ายดาย:python setup.py test
2. ตั้งค่า PYTHONPATH เมื่อทำการทดสอบ: PYTHONPATH=. python tests/runalltests.py

นี่คือวิธีการที่โค้ดรองรับใน M2Crypto:

• http://svn.osafoundation.org/m2crypto/trunk/setup.py
• http://svn.osafoundation.org/m2crypto/trunk/tests/alltests.py

หากคุณต้องการเรียกใช้การทดสอบด้วย nosetests คุณอาจต้องทำสิ่งที่แตกต่างกันเล็กน้อย

เราใช้

app/src/code.py
app/testing/code_test.py 
app/docs/..

ในไฟล์ทดสอบแต่ละเราแทรกใน../src/ sys.pathมันไม่ใช่ทางออกที่ดีที่สุด แต่ใช้ได้ ฉันคิดว่ามันจะดีถ้ามีใครมาด้วย waven คล้ายจาวาที่ให้การประชุมมาตรฐานที่ใช้งานได้ไม่ว่าคุณจะทำงานโครงการอะไร

หากการทดสอบนั้นง่ายเพียงใส่ไว้ใน docstring - กรอบการทดสอบส่วนใหญ่สำหรับ Python จะสามารถใช้งานได้:

>>> import module
>>> module.method('test')
'testresult'

สำหรับการทดสอบอื่น ๆ ที่เกี่ยวข้องมากขึ้นผมจะนำพวกเขาทั้งในหรือ../tests/test_module.pytests/test_module.py

ใน C # ฉันมักจะแยกการทดสอบเป็นชุดประกอบที่แยกต่างหาก

ใน Python - จนถึง - ฉันมักจะเขียน doctests โดยที่การทดสอบอยู่ใน docstring ของฟังก์ชั่นหรือวางไว้ในif __name__ == "__main__"บล็อกที่ด้านล่างของโมดูล

เมื่อเขียนแพ็คเกจที่เรียกว่า "foo" ฉันจะทดสอบหน่วยลงในแพคเกจแยกต่างหาก "foo_test" โมดูลและแพ็กเกจย่อยจะมีชื่อเหมือนกับโมดูลแพ็กเกจ SUT เช่นการทดสอบสำหรับโมดูล foo.xy พบได้ใน foo_test.xy ไฟล์ __init__.py ของแต่ละแพ็คเกจการทดสอบจะมีชุด AllTests ซึ่งรวมถึงชุดทดสอบทั้งหมดของแพ็คเกจ setuptools มีวิธีที่สะดวกในการระบุแพ็คเกจการทดสอบหลักดังนั้นหลังจาก "python setup.py พัฒนา" คุณสามารถใช้ "python setup.py test" หรือ "python setup.py test -s foo_test.x.SomeTestSuite" เพื่อ เพียงชุดเฉพาะ

ฉันวางการทดสอบของฉันในไดเรกทอรีเดียวกันกับรหัสที่อยู่ภายใต้การทดสอบ (CUT); สำหรับfoo.pyการทดสอบจะอยู่ในfoo_ut.pyหรือคล้ายกัน (ฉันปรับแต่งกระบวนการค้นพบทดสอบเพื่อค้นหาสิ่งเหล่านี้)

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

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

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

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

ดังนั้นฉันมี:

app /
 appfile.py
ทดสอบ/
 appfileTest.py

ฉันจะต้องดูว่ามันจะเป็นอย่างไรเมื่อฉันพัฒนาโครงการขนาดใหญ่