2009-06-11 12 views
21

इकाई परीक्षण में मैं जुड़नार लोड करने के लिए की जरूरत है, के रूप में नीचे:django इकाई परीक्षणों में केवल एक बार फिक्स्चर लोड करने के लिए कैसे?

class TestQuestionBankViews(TestCase): 

     # Load fixtures 
     fixtures = ['qbank'] 

     def setUp(self):       
      login = self.client.login(email="[email protected]",password="welcome")   


     def test_starting_an_exam_view(self):    
      candidate = Candidate.objects.get(email="[email protected]") 
      .......etc 


     def test_review_view(self): 
      self.assertTrue(True)    
      ......... 

     def test_review_view2(self): 
      self.assertTrue(True) 
      ......... 

समस्या:

इन जुड़नार, हर परीक्षा के लिए लोड कर रहे हैं यानी पहले test_review_view, test_review_view2, आदि , क्योंकि Django प्रत्येक परीक्षण के बाद डेटाबेस flushes।

यह व्यवहार परीक्षण को पूरा करने में काफी समय लग रहा है।

मैं इस अनावश्यक स्थिरता लोडिंग को कैसे रोक सकता हूं?

setUp में फिक्स्चर लोड करने का कोई तरीका है और टेस्ट क्लास समाप्त होने पर उन्हें फ़्लश करने के लिए, प्रत्येक परीक्षण के बीच फ़्लश करने के बजाय फ़्लश करें?

+0

ओह ......... मुझे लगता है कि मैं intial_data स्थिरता का उपयोग कर इसे हल कर सकता हूं और "test.estCase" के बजाय "unittest.Testcase" को विरासत में डाल सकता हूं? कोई अन्य विचार? –

उत्तर

3

मैं एक ही समस्या में भाग गया है। आम तौर पर, django के परीक्षण धावक का उपयोग करके ऐसा करने का वास्तव में अच्छा तरीका नहीं है। आपको इस thread

कहा जा रहा है कि, यदि सभी टेस्टकेस एक ही स्थिरता का उपयोग करते हैं, और वे डेटा को किसी भी तरह से संशोधित नहीं करते हैं, तो प्रारंभिक_डेटा का उपयोग करना होगा।

+0

पॉइंटर के लिए धन्यवाद, और हां (मैंने पहले इस बारे में सोचा नहीं था) हम केवल intial_data का उपयोग कर सकते हैं यदि प्रत्येक टेस्ट केस डेटाबेस –

+0

डेटाबेस को संशोधित नहीं करता है, तो मैंने intial_data के साथ unittest.TestCase का उपयोग करने का निर्णय लिया है। Django.test.TestCase द्वारा प्रदान की गई सभी सुविधाओं को कैसे प्राप्त करें इस पर कोई विचार है? –

1

मुझे एक बार एक ही समस्या थी और अपना खुद का परीक्षण धावक लिखना समाप्त हो गया। मेरे मामले में initial_data सही जगह नहीं थी क्योंकि initial_datasyncdb के दौरान लोड किया जाएगा, जो कुछ मैं नहीं चाहता था। परीक्षण सूट चलाने से पहले और इसे एक बार हटाने के लिए मैंने setup_ और teardown_test_environment विधियों को अपने कस्टम स्थिरता को लोड करने के तरीकों को ओवरराइड किया।

16

django-nose और थोड़ा सा कोड का उपयोग करके, आप वही कर सकते हैं जो आपने पूछा था। Django-nose के साथ, आपके पास प्रति-पैकेज, प्रति-मॉड्यूल और प्रति-वर्ग सेटअप और टियरडाउन फ़ंक्शन हो सकते हैं। इससे आप अपने फिक्स्चर को उच्च-अप सेटअप फ़ंक्शंस में से एक में लोड कर सकते हैं और django.test.TestCase को परीक्षणों के बीच जुड़नार के रीसेट करने को अक्षम कर सकते हैं।

from django.test import TestCase 
from django.core import management 

    def setup(): 
     management.call_command('loaddata', 'MyFixture.json', verbosity=0) 

    def teardown(): 
     management.call_command('flush', verbosity=0, interactive=False) 

    class MyTestCase(TestCase): 

     def _fixture_setup(self): 
      pass 

     def test_something(self): 
      self.assertEqual(1, 1) 

सूचना है कि सेटअप और टियरडाउन वर्ग के बाहर हैं:

यहाँ एक उदाहरण परीक्षण फ़ाइल है। सेटअप इस फ़ाइल में सभी टेस्ट क्लास से पहले चलाया जाएगा, और टियरडाउन सभी टेस्ट क्लास के बाद चलाया जाएगा।

कक्षा के अंदर, आप def _fixture_setup (self) विधि देखेंगे। यह उस फ़ंक्शन को ओवरराइड करता है जो प्रत्येक परीक्षण के बीच डेटाबेस को रीसेट करता है।

ध्यान रखें कि यदि आपके परीक्षण डेटाबेस में कुछ भी लिखते हैं, तो यह आपके परीक्षणों को अमान्य कर सकता है। तो प्रत्येक परीक्षण के लिए पुनः लोड किए गए फिक्स्चर की आवश्यकता वाले किसी भी अन्य परीक्षण को एक अलग परीक्षण फ़ाइल में रखा जाना चाहिए।

+0

+1 एक कार्यात्मक समाधान के लिए जो वास्तव में प्रारंभिक_डेटा.जेसन/यामल का उपयोग करने से भिन्न दृष्टिकोण के लिए कमरे छोड़ देता है। (मैं एक कस्टम प्रबंधन कमांड और एक स्क्रिप्ट का उपयोग करता हूं जो मेरा प्रारंभिक डेटा बनाने के लिए Django ORM को कॉल करता है। इससे मुझे इसे पूरी तरह से एकीकृत करने की सुविधा मिलती है।) यह स्वीकार्य उत्तर होना चाहिए, इससे मुझे बहुत मदद मिली! – hangtwenty

+1

महान समाधान! एक चीज जो मैंने पाया है वह काफी उपयोगी है। यदि आप def _fixture_setup (self) विधि में नहीं डालते हैं, और Django TestCase को सामान्य रूप से फाड़ने की अनुमति देते हैं, तो एक परीक्षण मामले में किए गए किसी भी डेटाबेस परिवर्तन अगले को प्रभावित नहीं करेंगे। ऐसा इसलिए है क्योंकि एक परीक्षण मामले की शुरुआत में, एक डेटाबेस लेनदेन शुरू किया जाता है, और आंसू चरण के दौरान परीक्षण केस डेटाबेस की स्थिति को रीसेट करने के लिए एक डीबी रोलबैक करेगा। तो def _fixture_setup() को अनदेखा कर आपको दोनों दुनिया के दांव देगा! – LeeMobile

9

या उपयोग setUpModule:

def setUpModule(): 
    print 'Module setup...' 

def tearDownModule(): 
    print 'Module teardown...' 

class Test(unittest.TestCase): 
    def setUp(self): 
     print 'Class setup...' 

    def tearDown(self): 
     print 'Class teardown...' 

    def test_one(self): 
     print 'One' 

    def test_two(self): 
     print 'Two' 

प्रिंट:

Creating test database for alias 'default'... 
Module setup... 
Class setup... 
One 
Class teardown... 
Class setup... 
Two 
Class teardown... 
Module teardown... 
+1

यह केवल तभी काम करता है जब मॉड्यूल पर प्रत्येक परीक्षण उसी स्थिरता का उपयोग करता है। दूसरे शब्दों में, यह आपको किसी दिए गए मॉड्यूल पर परीक्षण करने के लिए मजबूर करता है कि वे किस परीक्षण का उपयोग करते हैं, इसके बजाय वे क्या परीक्षण करते हैं। –

0

Django-नाक इस समस्या का एक रेडीमेड समाधान प्रदान करता है: बस django_nose.FastFixtureTestCase उपवर्ग।

इसके अतिरिक्त, django-nose स्थिरता बंडलिंग का समर्थन करता है, जो परीक्षण परीक्षण प्रति बार एक बार प्रत्येक अद्वितीय सेट फिक्स्चर लोड करके आपके परीक्षण को और भी तेज़ कर सकता है। FastFixtureTestCase उप-वर्गीकृत होने के बाद, --with-fixture-bundling विकल्प का उपयोग करके django-nose test runner चलाएं।

अधिक जानकारी के लिए django-nose on pypi देखें।

4

यदि आप इस उद्देश्य के लिए केवल एक नया पैकेज स्थापित नहीं करना चाहते हैं, तो आप Tom Wainwright's solution और mhost's solution जोड़ सकते हैं। , split the test into multiple files में एक नया निर्देशिका बनाने के द्वारा

from django.core.management import call_command 

def setUpModule(): 
    call_command(
     'loaddata', 
     'path_to_fixture.json', 
     verbosity=0 
    ) 

def tearDownModule(): 
    call_command('flush', interactive=False, verbosity=0) 

आप इन जुड़नार सभी प्रकार के परीक्षण के लिए डेटाबेस में लोड करने के लिए नहीं करना चाहते हैं:

अपने testfile में, किसी भी कक्षा के बाहर इन कार्यों को जोड़ने एप्लिकेशन tests कहा जाता है, अजगर बताने के लिए है कि यह एक पैकेज है, और फ़ाइल नाम है कि test के साथ शुरू के साथ अपने परीक्षण फ़ाइलें जोड़ते हैं, के बाद से धावक पैटर्न test*.py

3

मिलान क्या इसके लायक है के लिए फ़ाइलों के लिए दिखेगा एक खाली __init__.py फ़ाइल जोड़ने , और चूंकि कोई स्वीकार्य उत्तर नहीं है, इसलिए Django 1.8 अब इस कार्यक्षमता को बॉक्स के बाहर प्रदान करता है - बशर्ते आप एक डेटाबेस बैकएंड का उपयोग कर रहे हों जो लेनदेन का समर्थन करता हो।

यह टेस्टकेस कक्षा में एक बार परीक्षण डेटा के मैन्युअल निर्माण के लिए TestCase.setUpTestData() विधि भी जोड़ता है।

the Django 1.8 release notes देखें।

संबंधित मुद्दे