2013-01-22 27 views
7

क्या सिम्फनी 2 एप्लिकेशन में सही तरीके से यूनिट टेस्ट सिद्धांत मॉडल का कोई तरीका है? अभी मैं कार्यात्मक परीक्षण लिख रहा हूं जो यह सुनिश्चित करने के लिए नियंत्रक के माध्यम से जाता है कि मेरा एप्लिकेशन डेटा को सही तरीके से संग्रहीत कर रहा है (और CRUDING)। लेकिन यह बहुत लंबा लगता है और यह बहुत बुरा है, क्योंकि मुझे प्रत्येक सूट के लिए फिक्स्चर सेट करना होगा, और सूट समाप्त होने के बाद डेटाबेस को साफ़ करना होगा।सिम्फनी 2: सिद्धांत मॉडल का सही तरीके से परीक्षण कैसे करें?

मैं एंटिटी और एंटिटी रिपोजिटरी यूनिट परीक्षण कैसे अलग कर सकता हूं? क्या इस पर कोई ट्यूटोरियल उपलब्ध है?

+0

सिद्धांत ORM फ़ोल्डर में देखो, वहाँ एक testsuite ... परीक्षण से भरा है। – mpm

+0

वे सिद्धांत-उन्मुख इकाई परीक्षण हैं, सिद्धांत के लिए abstractTestSuites के साथ, मेरा आवेदन नहीं। मैं अपने बंडलों के अंदर अपने मॉडल का परीक्षण करने के यूनिट का एक सरल और उचित तरीका ढूंढ रहा हूं। – vinnylinux

उत्तर

0

एक चाल जो मैंने पाया जो यूनिट परीक्षण के लिए उपयोगी था, एसक्लाइट के फ़ाइल आधारित डेटाबेस का उपयोग करना है। आप 'blankdatabase.dat' नामक फ़ाइल में अपनी खाली डेटाबेस टेबल बना सकते हैं और इसे लोड करने के लिए एसक्लाइट का उपयोग कर सकते हैं। अब परीक्षण के अंत में, आप खाली डेटाबेस फ़ाइल को ओवरराइट कर सकते हैं और एक नए डेटाबेस से शुरू कर सकते हैं।

आप इस कोड के साथ खाली स्कीमा फ़ाइलें बना सकते हैं:

 $classes = array(
      $em->getClassMetadata('MyAPIBundle:Currency'), 
      $em->getClassMetadata('MyAPIBundle:Permission'), 
      $em->getClassMetadata('MyAPIBundle:Role'), 
      $em->getClassMetadata('MyAPIBundle:User'), 
     ); 

     $tool = new \Doctrine\ORM\Tools\SchemaTool($em); 
     $tool->createSchema($classes); 
     rename($schemafile, dirname(__FILE__) . '/../Data/schema.dat'); 

     print "Schema file was regenerated\n"; 

इसके अलावा

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

+0

यह पूरी तरह से अलग नहीं है, क्योंकि आपको फिक्स्चर सेट करना होगा और अपने चरणों को साफ़ करना होगा। – vinnylinux

+0

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

1

हमने टेस्टमैनेजर नामक एक सिंगल सेट अप किया है जो सेट अप करता है सभी परीक्षणों के लिए एक बार एक खाली परीक्षण डीबी। फिर हम setUp() विधि में किसी परीक्षण के लिए महत्वपूर्ण तालिकाओं को छोटा कर देते हैं और सिद्धांत API का उपयोग करके PHP में फिक्स्चर सेट अप करते हैं। हम इसके लिए MySQL का उपयोग करते हैं।

यह हमें phpunit की हर शुरुआत के लिए ~ 10s की देरी देता है, लेकिन यह परीक्षणों की संख्या से स्वतंत्र है। मुझे लगता है कि एसक्लाइट के इन-मेमोरी संस्करण का उपयोग कर इसे बहुत बढ़ाया जा सकता है।

व्यक्तिगत रूप से मैंने जोहान श्मिट के functional test for the payment core bundle के कोड को देखकर symfony2/सिद्धांत के साथ कार्यात्मक परीक्षण स्थापित करने के बारे में बहुत कुछ सीखा।

और केवल चीजों को स्पष्ट करने के लिए: यदि आप शुद्ध इकाई परीक्षण करना चाहते हैं तो आपको सभी को एक साथ सिद्धांत बनाना होगा। बाकी सब कुछ एक कार्यात्मक/एकीकरण परीक्षण है। लेकिन अक्सर यह विचलन बल्कि अकादमिक है और यह सिर्फ सिद्धांत के लिए काम करने के लिए बहुत अधिक काम है।

3

जब तक आप उन्हें डीबी तर्क से डीकॉप्ल नहीं करते हैं, तब तक आपको अपनी इकाइयों का परीक्षण करने में कोई समस्या नहीं होनी चाहिए।

और यहां रिपोजिटरी परीक्षण के बारे में बहुत अच्छा लेख है: https://symfony2-document.readthedocs.org/en/latest/cookbook/testing/doctrine.html

इसके अलावा आप इस क्यू & एक साथ रुचि हो सकती है: Testing Controllers in Symfony2 with Doctrine