यूनिट परीक्षण निष्पादन गति (प्रति सेकेंड कितने परीक्षण?)

Question

आप अपने यूनिट परीक्षण (प्रति सेकंड # टेस्ट) के साथ किस प्रकार की निष्पादन दर का लक्ष्य रखते हैं? एक व्यक्तिगत इकाई परीक्षण के लिए कितना समय लंबा है?

मुझे यह जानने में दिलचस्पी होगी कि क्या लोगों के पास यह निर्धारित करने के लिए कोई विशिष्ट सीमा है कि उनके परीक्षण बहुत धीमे हैं या क्या यह तब होता है जब लंबे समय तक चलने वाले परीक्षण सूट की घर्षण आपके लिए बेहतर हो जाती है?

अंत में, जब आप निर्णय लेते हैं कि परीक्षणों को तेजी से चलाने की आवश्यकता है, तो आप अपने परीक्षणों को तेज करने के लिए किस तकनीक का उपयोग करते हैं?

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

---

रिस्पांस राउंडअप: अब तक महान प्रतिक्रिया के लिए धन्यवाद। अधिकतर सलाह गति के बारे में चिंता न करें - गुणवत्ता पर ध्यान केंद्रित करें और यदि वे बहुत धीमी हैं तो उन्हें चुनिंदा रूप से चलाएं। विशिष्ट संख्याओं के साथ उत्तर में < 10ms तक 0.5 और 1 सेकंड प्रति परीक्षण का लक्ष्य शामिल है, या केवल 10 सेकेंड के तहत आमतौर पर रन परीक्षणों का पूरा सूट रखना शामिल है।

सुनिश्चित नहीं हूं कि यह सही एक "स्वीकार किए जाते हैं जवाब है" के रूप में एक चिह्नित करने के लिए जब वे बिल्कुल उपयोगी हो :)

Answer 1

सभी यूनिट परीक्षणों को एक सेकंड के तहत चलाना चाहिए (जो सभी यूनिट परीक्षण संयुक्त रूप से 1 सेकंड में चलाना चाहिए)। अब मुझे यकीन है कि इसमें व्यावहारिक सीमाएं हैं, लेकिन मेरे पास एक 1000 परीक्षणों वाला एक प्रोजेक्ट है जो लैपटॉप पर तेजी से चलता है। आप वास्तव में इस गति को चाहते हैं ताकि आपके डेवलपर्स मॉडल के कुछ मूल भाग को दोबारा तैयार न करें (यानी, लेमेम कुछ परीक्षण प्राप्त करते हैं जबकि मैं इन परीक्षणों को चलाता हूं ... 10 मिनट बाद वह वापस आता है)।

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

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

Answer 2

मैं गति की तुलना में मेरी परीक्षण की पठनीयता के बारे में अधिक ध्यान केंद्रित करते हैं है। हालांकि, मैं अभी भी उन्हें उचित रूप से तेज़ बनाने की कोशिश करता हूं। मुझे लगता है कि अगर वे मिलीसेकंड के आदेश पर चलते हैं, तो आप ठीक हैं। यदि वे प्रति परीक्षण एक या अधिक रन चलाते हैं ... तो आप कुछ ऐसा कर रहे हैं जिसे अनुकूलित किया जाना चाहिए।

धीमे परीक्षण केवल एक समस्या बन जाते हैं क्योंकि सिस्टम परिपक्व हो जाता है और निर्माण को घंटों तक ले जाता है, जिस बिंदु पर आप एक या 2 परीक्षणों के बजाय कई प्रकार के धीमे परीक्षणों के मुद्दे में भाग ले रहे हैं आसानी से अनुकूलित करें ... इस प्रकार आपको शायद सही ध्यान देना चाहिए यदि आप सैकड़ों मिलीसेकंड (या बदतर, सेकंड प्रत्येक) चलाने के कई परीक्षण देखते हैं, तब तक प्रतीक्षा करें जब तक कि वह लंबे समय तक चलने वाले सैकड़ों परीक्षणों तक न पहुंच जाए (जिस पर बिंदु यह समस्या को हल करने के लिए वास्तव में मुश्किल होने जा रहा है)।

फिर भी, यह केवल उस समय को कम करेगा जब आपके स्वचालित बिल्ड त्रुटियों को हल करता है ... ठीक है अगर यह एक घंटे बाद (या कुछ घंटों बाद भी) ठीक है, तो मुझे लगता है। समस्या से पहले समस्या चल रही है, लेकिन यह जांचने के लिए परीक्षणों का एक छोटा सबसेट चुनकर टाला जा सकता है जो आप काम कर रहे हैं उससे संबंधित हैं। बस निर्माण को ठीक करना सुनिश्चित करें यदि आप उस कोड को चेक करते हैं जो आपके द्वारा चलाए गए परीक्षणों को तोड़ देता है!

Answer 3

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

Answer 4

हम वर्तमान में लगभग 3.0 सेकंड में 270 परीक्षण पर हैं। फाइल आईओओ करने वाले लगभग 8 परीक्षण संभवतः हैं।

ये प्रत्येक इंजीनियर मशीन पर हमारे पुस्तकालयों के सफल निर्माण पर स्वचालित रूप से चलाए जाते हैं। हमारे पास अधिक व्यापक (और समय लेने वाला) धुआं परीक्षण है जो हर रात बिल्ड मशीन द्वारा किया जाता है, या इंजीनियरों मशीन पर मैन्युअल रूप से शुरू किया जा सकता है।

जैसा कि आप देख सकते हैं कि हम परीक्षणों की समस्या तक अभी तक समय तक नहीं पहुंच पाए हैं। मेरे लिए 10 सेकंड वह बिंदु है जहां यह घुसपैठ बनना शुरू होता है, जब हम उससे संपर्क करना शुरू करते हैं तो यह कुछ ऐसा होगा जो हम देखेंगे।हम निचले स्तर के पुस्तकालयों को स्थानांतरित करेंगे, जो अधिक मजबूत होते हैं क्योंकि वे बार-बार बदलते हैं और कुछ निर्भरताएं हैं, रात के निर्माण में, या कॉन्फ़िगरेशन जहां उन्हें केवल बिल्ड मशीन द्वारा निष्पादित किया जाता है।

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

आपका माइलेज स्पष्ट रूप से विकास के आपके क्षेत्र के आधार पर अत्यधिक चर होगा।

Answer 5

मैं प्रति परीक्षण आधार पर अपने यूनिट परीक्षणों का न्याय करता हूं, प्रति सेकंड # परीक्षणों द्वारा नहीं। जिस लक्ष्य का मैं लक्ष्य रखता हूं वह 500ms या उससे कम है। यदि यह उस से ऊपर है, तो मैं यह जानने के लिए परीक्षण में देखूंगा कि यह इतना समय क्यों ले रहा है।

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

Answer 6

UnitTest++ के लेखकों के पावर ऑफ टू गेम्स से good article पर इस पर good article था।

Answer 7

डाटा प्वाइंट - अजगर प्रतिगमन परीक्षण

यहाँ चल अजगर 2.5.2 के लिए "परीक्षण कर" के लिए अपने लैपटॉप पर नंबर दिए गए हैं:

• परीक्षण की संख्या: 3851 (लगभग)
• निष्पादन समय: 9 मिनट, 6 सेकंड
• निष्पादन दर: 7 परीक्षण/सेकंड

Answer 8

एक व्यक्ति यूनिट परीक्षण के लिए कितना समय लंबा है?

मैं कहूंगा कि यह संकलन गति पर निर्भर करता है। एक आम तौर पर प्रत्येक संकलन में परीक्षण निष्पादित करता है। यूनिट परीक्षण का उद्देश्य धीमा नहीं होना है, लेकिन एक संदेश लाने के लिए "कुछ भी टूटा नहीं है, पर जाएं" (या "कुछ तोड़ दिया, रोकें")।

मैं परीक्षण निष्पादन गति के बारे में परेशान नहीं करता जब तक कि यह कुछ ऐसा न हो जो परेशान हो जाए।

खतरे परीक्षण चलाने से रोकना है क्योंकि वे बहुत धीमी हैं।

अंत में, आप परीक्षण तेजी से चलाने की जरूरत है, क्या तकनीक आप अपने परीक्षण में तेजी लाने के प्रयोग करते हैं तय करते हैं जब?

पहली बात करने के लिए पता लगाने के लिए क्यों वे बहुत धीमी गति से कर रहे हैं का प्रबंधन करने के लिए है, और मुद्दा मौसम इकाई परीक्षण में या परीक्षण के अंतर्गत कोड में है?

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

Answer 9

लक्ष्य प्रति सेकेंड परीक्षण 100 है। माइकल फेदर के rules of unit tests का पालन करके आप जिस तरह से जाते हैं।

एक महत्वपूर्ण बिंदु जो पिछले CITCON चर्चा में आया था, यह है कि यदि आपके परीक्षण इस तेजी से नहीं हैं तो यह संभावना है कि आपको यूनिट परीक्षण के डिज़ाइन लाभ नहीं मिल रहे हैं।

Answer 10

कुछ ढांचे अंतिम संशोधित समय जैसे हेरिस्टिक पर आधारित विशिष्ट इकाई परीक्षणों के स्वचालित निष्पादन प्रदान करते हैं। रूबी और रेल के लिए, ऑटोटेस्ट परीक्षणों के बहुत तेज़ और उत्तरदायी निष्पादन प्रदान करता है - जब मैं रेल मॉडल app/models/foo.rb सहेजता हूं, test/unit/foo_test.rb में संबंधित यूनिट परीक्षण चलाते हैं।

मुझे नहीं पता कि अन्य प्लेटफार्मों के लिए कुछ भी समान है, लेकिन यह समझ में आता है।

Answer 11

इकाई परीक्षण के बारे में सबसे महत्वपूर्ण नियमों में से एक वे तेजी चलाना चाहिए है।

व्यक्तिगत इकाई परीक्षण के लिए कितना समय लंबा है?

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

आप अपने यूनिट परीक्षण (प्रति सेकंड # टेस्ट) के साथ किस प्रकार की निष्पादन दर का लक्ष्य रखते हैं?

आपको प्रत्येक टेस्ट को मिलीसेकंड के क्रम में चलाने के लिए लक्ष्य रखना चाहिए, 1 सेकंड से अधिक कुछ भी शायद परीक्षण कर रहा है।

वर्तमान में हमारे पास लगभग 800 परीक्षण हैं जो 30 सेकंड के भीतर चलते हैं, प्रति सेकेंड 27 परीक्षण। इसमें उन्हें चलाने के लिए आवश्यक मोबाइल एमुलेटर लॉन्च करने का समय शामिल है। उनमें से ज्यादातर 0-5ms लेते हैं (अगर मुझे सही याद है)।

हमारे पास एक या दो है जो लगभग 3 सेकंड लेते हैं, जो शायद जांच के लिए उम्मीदवार हैं, लेकिन महत्वपूर्ण बात यह है कि पूरे टेस्ट सूट में इतना समय नहीं लगता है कि यह डेवलपर्स को इसे चलाता है, और महत्वपूर्ण नहीं है हमारे निरंतर एकीकरण निर्माण धीमा करें।

हमारे पास एक कॉन्फ़िगर करने योग्य टाइमआउट सीमा भी 5 सेकंड तक सेट है - जो कुछ भी अधिक समय ले रहा है वह असफल हो जाएगा।