Autofixture: सुझाव: परीक्षणों के लिए "अरेंज एक्ट एसर्ट" शैली का पालन करें

इसका लाभ उठाएं। लेकिन मैं पहला अक्षर कैपिटल रखना पसंद करूंगा, वह है

// Arrange
// Act
// Assert

की बजाय

// arrange
// act
// assert

क्या आपके पास दूसरे मामले को प्राथमिकता देने के मजबूत कारण हैं?

नहीं, अपरकेस मेरे लिए ठीक है - यह पर्याप्त है कि हम एएए का उपयोग करें: ब्लश:

आप प्रत्येक चरण को एक रिक्त रेखा से भी अलग कर सकते हैं, जो कि आजकल मेरे द्वारा उपयोग किया जाने वाला स्वरूपण है। फिर, परीक्षण-पाठक यह मान सकता है कि यह दिया गया है/कब/फिर , या व्यवस्था/अधिनियम/जोर , या यहां तक ​​​​कि (चार चरण वाला यहां जाता है) ।

आप "सरल परीक्षण कोड के तीन से अधिक लाइनों के साथ" खंड में इस बारे में और अधिक पढ़ सकते हैं यहाँ ।

मैं ओएसएस में टिप्पणियों के बजाय खाली लाइनों के उपयोग को दृढ़ता से नापसंद करता हूं और उस मार्क्स विचार से असहमत हूं। मेरी टिप्पणी यहाँ देखें।

प्रत्येक परीक्षण-चरण के शीर्ष पर टिप्पणियाँ, मूल रूप से, टिप्पणियाँ हैं । और इस विशेष मामले में, वे क्षमाप्रार्थी हैं , क्योंकि वे समझाते हैं कि कैसे — बजाय क्यों ।

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

और इस विशेष मामले में, वे क्षमाप्रार्थी हैं

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

लेकिन शायद यह सिर्फ आदत की बात है

इस; और शायद यह भी कि वास्तव में परीक्षा किसने लिखी थी।

हैलो, मैं इससे निपटना चाहता हूं। मैं ऑटोफिक्स्चर का बहुत बड़ा प्रशंसक हूं और इसे अपने काम में हर समय इस्तेमाल करता हूं और यह वापस देने का एक अच्छा तरीका होगा।
तो मूल रूप से आप सभी परीक्षण फ़ाइलों में निम्नलिखित को बदलना चाहते हैं:
// Fixture setup से // Arrange
// Exercise System से // Act
// Verify Outcome से // Assert
और अंत में // Teardown से कुछ भी नहीं।

हां, लेकिन ध्यान रखें कि 'ढूंढें और बदलें' करना शायद काम न करे क्योंकि कुछ चरणों को कुछ परीक्षणों में एक साथ जोड़ा जाता है। यही है, आप व्यायाम प्रणाली में आ सकते हैं

@moodmosaic मैं समझता हूं, मैं फ़ाइल द्वारा फ़ाइल को पूर्ण 'ढूंढें और प्रतिस्थापित' नहीं करने की योजना बना रहा हूं, लेकिन मैं इसे अभी भी अधिक स्पष्ट/सरल मामलों में उपयोग कर सकता हूं।

शुक्रिया,
आइसा

@moodmosaic // Exercise system and verify outcome इसे इसके साथ बदला जाना चाहिए
// Act and Assert
या आप लोग कुछ अलग सोच रहे हैं?

आम तौर पर मैं // Act & Assert उपयोग करता हूं क्योंकि यह अधिक संक्षिप्त और शांत दिखता है जब तक @moodmosaic को चिंता न हो, मैं उस शैली का पालन करना पसंद करूंगा

किसी भी तरह से ठीक है :गर्दन:

तो मैं इस पर शुरू करने की कोशिश कर रहा हूं और वीएस 2017 में ऑल.एसएलएन लोड करने के बाद दो एफ # प्रोजेक्ट्स
( AutoFoq, AutoFoqUnitTest ) खुलने में विफल हो रहे हैं। मेरे पास एफ # के साथ शून्य अनुभव है इसलिए किसी भी मदद की सराहना की जाएगी

@micheleissa सुनिश्चित करें कि आप वीएस (15.5.1 या बाद के संस्करण) के नवीनतम संस्करण का उपयोग करते हैं, अन्यथा प्रोजेक्ट नहीं खुलेगा (एमएस ने अपने एफ # एसडीके में परिवर्तन लागू किया)। बंद वीएस के साथ रूट में git clean -fdx . चलाना भी सुनिश्चित करें। यह अस्थायी फ़ाइलों को साफ करने के लिए है यदि आपने पहले परियोजना की जाँच की थी।

उन दोनों कदमों से मदद मिलनी चाहिए। मुझे बताएं कि क्या उन्होंने . नहीं किया

@zvirja मैंने वीएस 2017 15.5.2 के नवीनतम संस्करण में अपग्रेड किया है और अभी भी उसी मुद्दे का सामना कर रहा है

क्या आपने दूसरे भाग की कोशिश की है?

• वी.एस. बंद करें
• नवीनतम master चेकआउट करें
• रूट पर जाएं और git clean -fdx . चलाएं
• वीएस फिर से खोलें?

ऐसा लगता है कि आपके पास पिछले एसडीके से बस बचा हुआ है।

यह भी सुनिश्चित करें कि आपकी मशीन पर F# टूलींग स्थापित है:

हाँ, मैं दूसरा भूल गया क्षमा करें :)
मैं इसे अभी कोशिश करूँगा

@zvirja जिसने काम किया, मदद करने के लिए बहुत बहुत धन्यवाद!

एक और सवाल, मैं अपने फोर्कड रेपो में जिस शाखा पर काम कर रहा हूं उसे इस टिकट से कैसे जोड़ूं?

बढ़िया है कि यह काम किया! मैं

मैं अपने फोर्कड रेपो में जिस शाखा में काम कर रहा हूं उसे इस टिकट से कैसे जोड़ूं?

मैं इस लेख को देखने का सुझाव दूंगा, वर्कफ़्लो का अच्छी तरह से वर्णन किया गया है: https://github.com/sevntu-checkstyle/sevntu.checkstyle/wiki/Development-workflow-with-Git:-Fork,-Branching,- प्रतिबद्ध,-और-पुल-अनुरोध

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

ठीक मिल गया। शुक्रिया! जब मैं इस मुद्दे पर काम कर रहा हूं, तो मैं पुल अनुरोध बनाऊंगा ताकि आप लोग प्रगति की निगरानी कर सकें और योगदान दिशानिर्देशों में उल्लिखित के अनुसार प्रतिक्रिया दे सकें।