एक राज्यव्यापी पायथन मॉड्यूल के साथ परीक्षण अलगाव को सही ढंग से कैसे प्राप्त करें?

Question

जिस परियोजना पर मैं काम कर रहा हूं वह एक पाइथन पैकेज के रूप में लिपटे एक व्यावसायिक तर्क सॉफ्टवेयर है। विचार यह है कि विभिन्न स्क्रिप्ट या एप्लिकेशन इसे आयात करेगा, इसे आरंभ करें, फिर इसका उपयोग करें।

वर्तमान में इसमें शीर्ष स्तर की init() विधि है जो प्रारंभिकता और विभिन्न चीजों को सेट करती है, एक अच्छा उदाहरण यह है कि यह SQLAlchemy को डीबी कनेक्शन के साथ सेट करता है और बाद में एक्सेस के लिए एसए सत्र स्टोर करता है। यह मेरे प्रोजेक्ट के उप-पैकेज में संग्रहीत किया जा रहा है (अर्थात् myproj.model.Session, इसलिए मॉडल को आयात करने के बाद अन्य कोड एक एसए सत्र प्राप्त कर सकता है)।

लंबी कहानी छोटी, यह मेरे पैकेज को एक स्टेटफुल बनाता है। मैं इस परियोजना के लिए इकाई परीक्षण लिख रहा हूँ और इस stafeful व्यवहार कुछ समस्या बन गया है:

1. परीक्षण अलग करना चाहिए, लेकिन मेरे पैकेज की आंतरिक स्थिति यह अलगाव टूट जाता है
2. मैं मुख्य init परीक्षण नहीं कर सकते() विधि के बाद से अपने व्यवहार राज्य पर निर्भर करता है
3. भविष्य परीक्षण मैं के खिलाफ चलाने के लिए (अभी तक नहीं लिखा) एक प्रसिद्ध मॉडल राज्य के साथ नियंत्रक हिस्सा आवश्यकता होगी (जैसे। एक पहले से भरा sqlitein-memory db)

चाहिए किसी भी तरह से मेरे packag refactor ई क्योंकि वर्तमान संरचना सर्वश्रेष्ठ (संभव) अभ्यास (टीएम) नहीं है? :)

क्या मुझे इसे उस पर छोड़ देना चाहिए और हर बार पूरी चीज को सेटअप/टियरडाउन करना चाहिए? अगर मैं पूर्ण अलगाव प्राप्त करने जा रहा हूं जिसका मतलब है कि प्रत्येक परीक्षण में पूरी तरह से मिटाना और डीबी को फिर से पॉप्युलेट करना, तो अधिक नहीं है?

यह प्रश्न वास्तव में समग्र कोड & परीक्षण संरचना पर है, लेकिन इसके लिए मेरे मूल्य के लिए मैं nose-1.0 का उपयोग कर रहा हूं। मुझे पता है कि Isolate plugin शायद मेरी मदद कर सकता है लेकिन मैं टेस्ट सूट में अजीब चीजें करने से पहले कोड प्राप्त करना चाहता हूं।

Answer 1

आप कुछ ही विकल्प हैं।

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

यह आम तौर पर परीक्षण अलगाव के लिए सबसे शुद्ध है क्योंकि यह परीक्षण से संभावित रूप से बड़ी निर्भरता को कम करता है। यह परीक्षणों को तेज़ी से बनाता है और एक सतत एकीकरण वातावरण कहने में टेस्ट सूट को स्वचालित करने के लिए ओवरहेड को कम करता है।

प्रत्येक टेस्ट के साथ डीबी पुन:

व्यापार नापसंद के बारे में पता किया जाना है।

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

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

ORM डीबी स्वैप

अपने SQLAlchemy की तरह एक ORM का उपयोग कर अपने एक संभावना है कि आप एक संभावित तेजी में स्मृति डेटाबेस के साथ अंतर्निहित डेटाबेस स्वैप कर सकते हैं है। यह आपको पिछले विकल्पों दोनों के कुछ नकारात्मकों को कम करने की अनुमति देता है।

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

Answer 2

एक अपेक्षाकृत महंगे सेटअप (आईपीथन) के साथ एक परियोजना पर काम करना, मैंने एक दृष्टिकोण देखा है जहां हम get_ipython फ़ंक्शन को कॉल करते हैं, जो सेट अप करता है और एक उदाहरण देता है, जबकि एक फ़ंक्शन के साथ स्वयं को प्रतिस्थापित करता है जो संदर्भ देता है मौजूदा उदाहरण फिर प्रत्येक परीक्षण एक ही फ़ंक्शन को कॉल कर सकता है, लेकिन यह केवल पहले के लिए सेटअप करता है।

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

Answer 3

Mock कुछ अलगाव प्राप्त करने के लिए एक सरल और शक्तिशाली उपकरण है। Pycon2011 से एक अच्छा video है जो दिखाता है कि इसका उपयोग कैसे करें। मैं इसे py.test के साथ एक साथ उपयोग करने की अनुशंसा करता हूं जो परीक्षण को परिभाषित करने के लिए आवश्यक कोड की मात्रा को कम करता है और अभी भी बहुत शक्तिशाली है।

नकली डेटाबेस

कुछ व्यापार नापसंद के बारे में पता होना करने के लिए कर रहे हैं: