क्या कोई विजुअल-सी ++ के साथ "वास्तविक" टीडीडी कर रहा है, और यदि हाँ, तो वे इसे कैसे करते हैं? [बन्द है]

10

बंद हो गया । इस प्रश्न पर अधिक ध्यान देने की आवश्यकता है । यह वर्तमान में उत्तर स्वीकार नहीं कर रहा है।

इस प्रश्न को सुधारना चाहते हैं? प्रश्न को अपडेट करें ताकि यह इस पोस्ट को संपादित करके केवल एक समस्या पर केंद्रित हो ।

4 साल पहले बंद हुआ ।

टेस्ट ड्रिवेन डेवलपमेंट का अर्थ है कोड से पहले टेस्ट लिखना और एक निश्चित चक्र का अनुसरण करना :

टेस्ट लिखो
परीक्षण जांचें (चलाएँ)
उत्पादन कोड लिखें
परीक्षण जांचें (चलाएँ)
उत्पादन कोड को साफ करें
परीक्षण जांचें (चलाएँ)

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

अब, जबकि वहाँ सी के लिए यूनिट परीक्षण फ़्रेमवर्क ++ (मैं Bost.Test एटीएम का उपयोग कर रहा हूँ।) के बहुत सारे मौजूद यह है कि वहाँ प्रतीत होता है नहीं करता है वास्तव में किसी भी सभ्य (के लिए मौजूद हैं देशी सी ++ ) दृश्य स्टूडियो (प्लगइन) समाधान है कि TDD बनाता है उपयोग की गई फ्रेमवर्क की परवाह किए बिना साइकिल बीरबल।

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

तो, कौन से उपकरण (प्लगइन्स) और तकनीकें हैं जो विजुअल स्टूडियो के साथ देशी C ++ के विकास के लिए TDD चक्र को संभव बनाते हैं?

नोट: मैं मुफ़्त या "वाणिज्यिक" टूल के साथ ठीक हूं।

कृपया : कोई रूपरेखा अनुशंसाएँ। (जब तक कि फ्रेमवर्क में एक समर्पित विज़ुअल स्टूडियो प्लगइन नहीं है और आप प्लगइन की सिफारिश करना चाहते हैं।)

नोट संपादित करें : अब तक के उत्तरों ने यूनिट टेस्टिंग फ्रेमवर्क को विज़ुअल स्टूडियो में एकीकृत करने के तरीके के बारे में लिंक प्रदान किए हैं। संसाधनों का कमोबेश वर्णन है कि कैसे यूटी ढांचे को संकलित करने के लिए और अपने पहले टेस्ट को चलाने के लिए प्राप्त करें। यह वह जगह है नहीं क्या इस सवाल के बारे में है। मेरी राय है कि वास्तव में उत्पादक रूप से काम करने के लिए, यूनिट टेस्ट को मैन्युअल रूप से बनाए रखा गया है (!), आपके उत्पादन वर्गों से अलग vcproj इतना ओवरहेड जोड़ देगा कि टीडीडी "संभव नहीं है"। जहां तक मुझे जानकारी है, आप यूनिट टेस्ट और टीडीडी को सक्षम करने के लिए एक जावा या सी # चीज के लिए अतिरिक्त "प्रोजेक्ट" नहीं जोड़ते हैं, और एक अच्छे कारण के लिए। यह होना चाहिए C ++ के साथ सही उपकरण दिए जा सकते हैं, लेकिन ऐसा लगता है (यह सवाल है) कि TDD / C ++ / VS के लिए बहुत कम उपकरण हैं।

चारों ओर घूमते हुए, मुझे एक उपकरण मिला है, विजुअलएसेटर , जो सही दिशा में लक्ष्य बनाता है । हालाँकि, afaiks, यह व्यापक उपयोग में नहीं लगता (CppUnit, Boost.Test आदि की तुलना में)।

संपादित करें: मैं इस प्रश्न के संदर्भ के लिए एक टिप्पणी जोड़ना चाहूंगा। मुझे लगता है कि यह समस्या के रूपरेखा (भाग) का एक अच्छा सारांश है: ( बिली ओनेल द्वारा टिप्पणी )

विज़ुअल स्टूडियो "बिल्ड स्क्रिप्ट" का उपयोग नहीं करता है जो उपयोगकर्ता द्वारा यथोचित संपादन योग्य हैं। एक प्रोजेक्ट एक बाइनरी पैदा करता है। इसके अलावा, जावा में ऐसी संपत्ति है जो जावा कभी भी एक पूर्ण बाइनरी नहीं बनाता है - आपके द्वारा बनाया गया बाइनरी केवल क्लास फ़ाइलों का एक ज़िप है। इसलिए अलग-अलग संकलन करना संभव है, फिर JAR को मैन्युअल रूप से (उदाहरण 7z का उपयोग करके)। C ++ और C # दोनों वास्तव में उनके बायनेरिज़ को लिंक करते हैं, इसलिए आम तौर पर बोलकर आप उस तरह की स्क्रिप्ट नहीं लिख सकते हैं। निकटतम आप प्राप्त कर सकते हैं सब कुछ अलग से संकलित करें और फिर दो लिंकिंग करें (उत्पादन के लिए एक, परीक्षण के लिए एक)।

— मार्टिन बा
स्रोत

2

As far as I am aware, you do not add extra "projects" to a Java or C# thing to enable Unit Tests and TDD,<- मुझे नहीं लगता कि यह सही है। आपके पास आमतौर पर C # में कई परियोजनाएं हैं; आप अपने उत्पादन बाइनरी में अपने परीक्षण कोड को शिप नहीं करना चाहते हैं।

— बिली ओनेल

2

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

— बिली ओपल

1

@ बिलियन, मेरी सभी (जावा) परियोजनाओं में से एक है, इस परियोजना में मुख्य और परीक्षण स्रोत शामिल हैं - निर्माण की स्क्रिप्ट तब चुनिंदा कलाकृतियों में क्या टुकड़े डालते हैं।

— रॉबर्ट मार्क ब्रैम

2

@ रॉबर्ट: विज़ुअल स्टूडियो "बिल्ड स्क्रिप्ट" का उपयोग नहीं करता है जो उपयोगकर्ता द्वारा यथोचित संपादन योग्य हैं। एक प्रोजेक्ट एक बाइनरी पैदा करता है। इसके अलावा, जावा के पास ऐसी संपत्ति है जो जावा कभी भी पूर्ण बाइनरी नहीं बनाता है - आपके द्वारा बनाया गया बाइनरी केवल क्लास फ़ाइलों का एक ज़िप है। इसलिए अलग-अलग संकलन करना संभव है, फिर JAR को मैन्युअल रूप से (उदाहरण के लिए 7z) एक साथ । C ++ और C # दोनों वास्तव में उनके बायनेरिज़ को लिंक करते हैं, इसलिए आम तौर पर बोलकर आप उस तरह की स्क्रिप्ट नहीं लिख सकते हैं। निकटतम आप प्राप्त कर सकते हैं सब कुछ अलग से संकलित करें और फिर दो लिंकिंग करें (उत्पादन के लिए एक, परीक्षण के लिए एक)।

— बिली ओनेल

4

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

— कानूनी रूप से वैध

4

मैंने C ++ और विजुअल स्टूडियो के साथ TDD करने पर 5-भाग की ब्लॉग श्रृंखला लिखी है: भाग 1 , भाग 2 , भाग 3 , भाग 4 , भाग 5 ।

मुझे यकीन नहीं है कि आप क्यों कहते हैं कि आप TDD करने के लिए C # में अतिरिक्त प्रोजेक्ट नहीं बनाते हैं, क्योंकि यही मैंने हमेशा NUnit के साथ किया है और यह विशिष्ट है कि अन्य लोग NUnit के साथ भी क्या करते हैं। कारण सरल है: हमेशा परीक्षण कोड को उत्पादन कोड से अलग रखें। विजुअल स्टूडियो के साथ C ++ के लिए, इसका मतलब अलग-अलग प्रोजेक्ट्स की तरह ही यह C # और NUnit के लिए है। मैं जावा दुनिया के बारे में जो कुछ जानता हूं, यह वहां भी आम है।

जाहिर है, हर किसी के पास टीडीडी करने के लिए "सहने योग्य" क्या है, इसके बारे में अलग-अलग विचार हैं। मैं अपने ब्लॉग पोस्ट में गंभीर वर्षों के लिए जिस पद्धति की रूपरेखा तैयार कर रहा हूं, उसका अभ्यास कर रहा हूं और मुझे यह बहुत अच्छा लगता है। C ++ एक संकलित भाषा है और संकलन सामग्री धीमी हो सकती है जब परीक्षण के तहत प्रणाली अत्यधिक युग्मित होती है। वहाँ बस किसी से दूर हो रही है कि एक और अधिक युग्मित डिजाइन करने के लिए refactoring के बिना नहीं है।

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

दी गई, C ++ का संकलन समय प्रकृति इसे TDD प्रक्रिया के प्रत्येक चक्र में NUnit और C # के साथ थोड़ा अधिक समय लेती है, लेकिन मुझे अपने सुव्यवस्थित C ++ कोड से जो आत्मविश्वास मिलता है, वह इसके लायक है। अन्यथा मैं डिबगर में बहुत अधिक समय बिताने जा रहा हूं। मैं सावधानी बरतने के लिए अपने गम के उपयोग में बख्शा जा सकता हूं क्योंकि यह संकलन समय का परीक्षण करने के लिए पर्याप्त रूप से जोड़ सकता है। मैं अब तक ज्यादातर हल्के "नकली" वस्तुओं से दूर हो गया हूं और शायद ही कभी फॉक्स की पूर्ण कार्यक्षमता की आवश्यकता होती है। C ++ के लिए मॉकिंग फ्रेमवर्क बहुत अधिक टेम्पलेट आधारित हैं और यह संकलन समय को काफी बढ़ा सकता है, इसलिए उन्हें उस स्थान के लिए आरक्षित किया जाना चाहिए जहां आपको वास्तव में एक नकली की आवश्यकता होती है और एक नकली बस नहीं चलेगा।

मैंने उत्पादन कोड के लिए परीक्षण परियोजना बनाने के कुछ बॉयलर प्लेट प्रकृति को स्वचालित करने के लिए एक Boost.Test यूनिट टेस्ट प्रोजेक्ट विज़ार्ड बनाने पर विचार किया है, लेकिन जब आपने इसे एक दो बार किया है, तो यह वास्तव में मैन्युअल रूप से करने के लिए कठिन नहीं है।

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

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

— वैध बनाना
स्रोत

"... मुझे यकीन नहीं है कि आप यह क्यों कहते हैं कि आप C # में अतिरिक्त प्रोजेक्ट नहीं बनाते हैं ... मुझे जावा दुनिया के बारे में जो पता है, यह भी आम है ..." मेरी तरफ से एक गलत धारणा रही है। (.NET के लिए कम से कम, क्योंकि आपको .NET के लिए एक निष्पादन योग्य की आवश्यकता है - जावा के लिए आपको बस क्लास फ़ाइलों की आवश्यकता है, इसलिए मुझे यह नहीं देखना है कि अतिरिक्त प्रोजेक्ट कहां फिट होगा।)

— मार्टिन बा

मुझे यकीन नहीं है कि जावा परियोजनाओं के साथ कैसे काम करता है; मुझे वहां सीमित अनुभव है। मैं जो कुछ भी जानता हूं, उससे मैं समझता हूं कि परियोजनाएं आईडीई की कलाकृतियां हैं न कि भाषा। (सख्ती से बात करते हुए, यह C # के लिए भी सही है, लेकिन मैं किसी को भी नहीं जानता कि सिर्फ छोटे ब्लॉग लेखों या प्रदर्शनों के अलावा किसी और चीज के लिए कमांड-लाइन कंपाइलर का उपयोग करता है।) हालांकि, यहां तक कि जावा में भी आप निश्चित रूप से टेस्ट कोड को अलग रखते हैं। उत्पादन कोड, जो आपके लिए अलग-अलग परियोजनाएं कर रहा है। मैं कभी भी उत्पादन और परीक्षण कोड को अलग करने के लिए सशर्त रूप से C ++ की सिफारिश नहीं करता।

— वैध

1

"परीक्षण कोड को उत्पादन कोड से अलग रखें, जो कि आपके लिए अलग परियोजनाएं कर रहा है" - अहा! खैर, वास्तव में नहीं, IMHO। C ++ और .NET के लिए अलग "प्रोजेक्ट" एक आवश्यकता है, क्योंकि दोनों को कुछ भी चलाने के लिए एक निष्पादन योग्य बनाने और एक (एक) निष्पादन योग्य बनाने के लिए आपको एक (एक) प्रोजेक्ट की आवश्यकता है। मैं उत्पादन कोड से परीक्षण कोड को अलग रखने (या नहीं) के साथ ठीक हूं, लेकिन मुझे परीक्षण निष्पादन योग्य कष्टप्रद उत्पन्न करने के लिए एक (निरर्थक) "प्रोजेक्ट" जोड़ना है। :-)

— मार्टिन बा

1

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

— वैध करें

2

मैं Visual-C ++ का उपयोग नहीं कर रहा हूं, लेकिन मैं अपनी IDE के रूप में QtCreator के साथ, Googletest और googlemock का उपयोग करके C ++ के साथ TDD का प्रदर्शन कर रहा हूं। वर्षों पहले मेरे पास विज़ुअल-सी ++ के साथ एक समान सेटअप था लेकिन एक अलग इकाई परीक्षण ढांचे का उपयोग कर रहा था।

जो मैंने उपयोगी पाया है वह परियोजना को कुछ उप-परियोजनाओं में अलग करना है।

एक स्थिर या गतिशील पुस्तकालय जिसमें वास्तविक परियोजना स्रोत कोड का 99% होता है।
एक परियोजना जिसमें सामान्य कार्यक्रम को चलाने के लिए ज्यादातर एक मुख्य () पद्धति होती है।
एक परीक्षण परियोजना जिसमें मेरा परीक्षण ढाँचा चलाने के लिए एक मुख्य () शामिल है और बहुत सारी फाइलें जिनमें परीक्षण और नकली चीजें हैं।

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

फ़ाइल Foo.cpp के लिए इकाई परीक्षण चलाने के लिए फ़ाइल के लिए अपने IDE में एक कस्टम लॉन्चर जोड़ना संभव हो सकता है यदि आपने परीक्षण स्थिरता परीक्षण के तहत फू के लिए सभी इकाई परीक्षणों का नाम दिया है। विज़ुअल-सी ++ के लिए इसे ठीक से कैसे सेट किया जाए, मुझे यकीन नहीं है, लेकिन मुझे लगता है कि यह संभव है।

— कोरी डी
स्रोत

उपयोगी जानकारी, हालांकि मैं इसे "सामान्य सलाह" कहने के लिए बहुत दूर जाऊंगा :-) ... यह भी हमारे विरासत सामान के लिए वास्तव में संभव नहीं है, लेकिन फिर विरासत सामान में परीक्षण जोड़ना वैसे भी एक दर्द है ( (मैं परीक्षा में हेराफेरी को कम से कम जोड़ना आसान बनाना चाहता था)।

— मार्टिन बा

2

मैं मूल C ++ कोड के परीक्षण के लिए MSTest का उपयोग करता हूं।
यहाँ इस तरह के बारे में महान ब्लॉग पोस्ट है: http://blogs.msdn.com/b/jsocha/archive/2010/11/19/writing-unit-tests-in-visual-studio-for-native-c। aspx

हां, कम से कम दो परियोजनाएं होंगी - एक आवेदन के लिए, एक परीक्षण के लिए।
स्टैटिक लाइब्रेरी के साथ तीसरी परियोजना बनाने के बजाय, मैं परीक्षण परियोजना के लिए आवेदन के स्रोत को जोड़ता हूं, इसलिए समाधान इस तरह दिखता है:

[-] Solution 'Foo'      Foo\Foo.sln
 |-[-] Foo              Foo\Foo\Foo.vcproj
 |  |-[-] include
 |  |  |- foo.h         Foo\Foo\foo.h
 |  |  |- bar.h         Foo\Foo\bar.h
 |  |
 |  |-[-] source
 |     |- foo.cpp       Foo\Foo\foo.cpp
 |
 |-[-] Foo.Tests        Foo\Foo.Tests\Foo.Tests.vcproj
    |                        (Additional include directory: "..\Foo")
    |-[-] include
    |  |- FakeBar.h     Foo\Foo.Tests\FakeBar.h
    |
    |-[-] source
       |-[-] app
       |  |- foo.cpp    Foo\Foo\foo.cpp    -- not in Foo.Tests\
       |
       |-[-] unit-tests
          |- foo_Tests.cpp   Foo\Foo.Tests\foo_Tests.cpp
          |- bar_Tests.cpp   Foo\Foo.Tests\bar_Tests.cpp

— Abyx
स्रोत

मुझे लगता है कि यूनिट टेस्टिंग के लिए C ++ / CLI सामान का उपयोग करने से शुद्ध देशी C ++ कोड का परीक्षण करने पर पानी की मात्र कम हो जाती है। हालाँकि, मैंने C ++ / CLI एप्लिकेशन कोड का परीक्षण करने के लिए NUnit का उपयोग किया है। मैंने C # में अपने परीक्षण लिखे और यह ठीक काम किया। (मौजूदा कोड आधार C ++ / CLI था और मैं इसे C # पर पोर्ट नहीं करना चाहता था।)

— कानूनी रूप दें

इसके अलावा, यदि आपके परीक्षण C ++ / CLI में हैं, तो आप उन्हें अन्य प्लेटफार्मों पर नहीं चला सकते हैं। अधिकांश स्थानों पर जहां मैंने C ++ का उपयोग किया है, उन्हें क्रॉस-प्लेटफॉर्म संकलन एबिलिटी की आवश्यकता थी। बेशक आप अन्य प्लेटफार्मों पर वीएस परियोजना का पुन: उपयोग नहीं कर सकते हैं, लेकिन इसके लिए मेकफाइल्स या स्कैनस्क्रिप्ट होना कोई बड़ी बात नहीं है।

— वैध

@ कानूनी रूप से हम गैर-विंडोज प्लेटफार्मों पर भी WinAPI (और COM और अन्य विंडोज-विशिष्ट तकनीकों) का पुन: उपयोग नहीं कर सकते।

— अब्येक

हां, निश्चित रूप से आप गैर-विंडोज प्लेटफार्मों पर विंडोज विशिष्ट तकनीकों का उपयोग नहीं कर सकते हैं। मेरा अवलोकन बस इतना था कि यदि आपके पास प्लेटफ़ॉर्म अज्ञेयवादी कोड है, तो आप अपनी यूनिट परीक्षणों को किसी विशेष प्लेटफ़ॉर्म पर बाँधना नहीं चाहते हैं। पिछले नियोक्ता में, हमने बड़ी संख्या में यूनिट टेस्ट फ्रेमवर्क और विधियों का मूल्यांकन किया। हमने Boost.Test को चुना क्योंकि यह क्रॉस प्लेटफॉर्म था और यूनिट टेस्टिंग के संबंध में C ++ मानक पुस्तकालय में कुछ भी कभी खत्म होने वाला था, तो यह संभवतः Boost.Test होगा।

— कानूनी रूप

2

शायद दिन में थोड़ी देर हो गई, लेकिन अगर मैंने आपके सवाल को सही ढंग से पढ़ा, तो आप TDD चक्र को बेहतर बनाने के लिए तकनीकों की तलाश कर रहे हैं? यह यहाँ उल्लेख नहीं किया गया है, लेकिन क्या आपने वीएस में निर्माण के बाद की घटनाओं को देखा है?

हमारे समाधान आम तौर पर आयोजित किए जाते हैं (प्रोजेक्ट डिपेंडेंसी के साथ) ...

MAIN-APP > LIB1, LIB2, UNIT-TEST-APP
UNIT-TEST-LIB1 > LIB1
UNIT-TEST-LIB2 > LIB2
UNIT-TEST-APP > UNIT-TEST-LIB1, UNIT-TEST-LIB2

MAIN-APP का पोस्ट-बिल्ड इवेंट UNIT-TEST-APP चलाएगा

UNIT-TEST-APP की पोस्ट-बिल्ड ईवेंट स्वयं (बस-बिल्ड इवेंट में चलाने के लिए कमांड के रूप में '$' (TargetPath) 'चलाएगी)।

(इसका मतलब यह है कि MAIN-APP का निर्माण करते समय, यूनिट परीक्षण दो बार चल सकते हैं, लेकिन यह वास्तव में हमारे मामले में कोई समस्या नहीं है!)

जैसा कि उल्लेख किया गया है, हां, इस संरचना को स्थापित करने में थोड़ा प्रयास है, लेकिन एक बार वहां जाने के बाद, परीक्षणों को जोड़ना सरल है।

तो आपको बस इतना करना है कि मुख्य ऐप का निर्माण करें और इकाई परीक्षण स्वचालित रूप से चलेंगे!

— स्टीव फोली
स्रोत

1

ठीक है, पता नहीं कि यह मदद करता है, लेकिन ब्रेट एल शुचर्ट से टीडीडी के बारे में कुछ बेहतरीन वीडियो हैं। दुर्भाग्य से, वह संयोजन "सी ++" और "वीएस" नहीं दिखाता है, लेकिन

TD # के साथ C # और VS: http://vimeo.com/album/210446

टीडीडी सी ++ और ग्रहण के साथ: http://vimeo.com/13240481

शायद आप इसे उन दो में से काम कर सकते हैं।

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

http://schuchert.wikispaces.com/tdd.cpp.NotesOnCppUTest

जो आपको Visual Studio में CppUTest का उपयोग करने की जानकारी देता है।

— डॉक्टर ब्राउन
स्रोत

2

Doc - मैंने (केवल) TDD / Eclipse वीडियो को देखा है, लेकिन मैं इसे नीचे करने जा रहा हूं। वीडियो बिल्कुल वही दिखा रहा है जिसमें मुझे कोई दिलचस्पी नहीं है, अर्थात् यूनिट टेस्ट कोड कैसे लिखना है। समस्या (इस प्रश्न में) यूनिट टेस्ट नहीं लिख रही है, यह है कि उन्हें आपके सी ++ उत्पादन विकास के साथ ठीक से कैसे एकीकृत किया जाए और मैं नहीं देखता कि ये वीडियो यहां कैसे मदद करते हैं।

— मार्टिन बा

जब मैंने इस प्रश्न के संदर्भ में इस उत्तर को अस्वीकार कर दिया, तो मैं जोड़ना चाहूंगा कि वीडियो काफी अच्छे हैं। मुझे ग्रहण / TDD / C ++ देखने में दिलचस्प लगा। यह यहाँ मदद नहीं करता है :-)

— मार्टिन बा

@ मार्टिन: मेरा संपादन देखें।

— डॉक्टर ब्राउन

आपके प्रयास की सराहना की जाती है और जब तक मुझे नहीं लगता कि यह अतिरिक्त लिंक वास्तव में इस प्रश्न के संदर्भ में मददगार है, मुझे लगता है कि मुझे अपना संपादन स्वयं करने की आवश्यकता होगी।

— मार्टिन बा

@Martin: ठीक है, मैंने आपका प्रश्न फिर से पढ़ा और आपकी "बीबरबल" की परिभाषा, लेकिन क्या आप बहुत अधिक उम्मीद नहीं करते हैं? एक इकाई परीक्षण परियोजना की स्थापना एक "एक क्लिक" समाधान नहीं है, लेकिन वास्तविक इकाई परीक्षणों को लिखने की कोशिश है जो परिमाण के आदेशों द्वारा, जो भी आप उपयोग कर रहे हैं।

— डॉक्टर ब्राउन

1

Googletest
vc ++ के साथ कैसे एकीकृत किया जाए

आप एक प्लगइन की जरूरत नहीं है, परीक्षण सिर्फ एक और लक्ष्य है। वहाँ सी + + के साथ परीक्षण उत्पन्न करने के लिए प्लगइन्स नहीं हैं, अगर आप इसे काम की तरह व्यर्थ सामान का परीक्षण किया जाएगा

— मार्टिन बेकेट
स्रोत

"यहां तक कि अगर आप इसे असाइनमेंट की तरह व्यर्थ सामान का परीक्षण कर रहे होंगे" - इसका क्या मतलब है? क्या आप वास्तव में सोचते हैं कि C ++ में यूनिट टेस्ट के लिए बेहतर आईडीई समर्थन बेकार है ??

— मार्टिन बा

मेरा मतलब है कि c ++ जैसी भाषा में सिस्टम स्पष्ट बयानों के अलावा किसी अन्य चीज के लिए स्वतः परीक्षण नहीं कर सकता है

— मार्टिन बेकेट

2

क्यों नहीं? ऑटो vcprojपर एक फ़ाइल को उत्पन्न करने के लिए एक प्लगइन में बाधा क्या है , उसने मेरे द्वारा लिखी गई परीक्षण फ़ाइल फ़ाइल और संदर्भित उत्पादन फ़ाइल में खींच लिया है और उसे चलाने की कोशिश कर रहा है? (बस सपना देख रहा है, लेकिन यह काम करने के लिए बनाया जा सकता है।)

— मार्टिन बा

2

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

— मार्टिन बा

2

नहीं, मैंने परीक्षण-कोड का उल्लेख नहीं किया, बल्कि प्रोजेक्ट / कंपाइलर मचान के लिए परीक्षण-कोड प्लस "चलाने के लिए" यह "उत्पादन कोड" प्राप्त करने की आवश्यकता थी।

— मार्टिन बा

1

C ++ टूल पर टिप्पणी नहीं कर सकता क्योंकि मैंने लगभग 20 वर्षों में (.NET dev इन दिनों) छुआ नहीं है और मुझे लगता है कि इन दिनों अधिकांश उपकरण प्रबंधित कोड के लिए हैं, लेकिन तकनीकों के लिए ...

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

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

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

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

छोटा कैविएट: मैं सालों पहले एजाइल कूल-एड से नशे में था: डी

— क्रिस ली
स्रोत

नोट: मेरे पास पहले से ही Working Effectively with Legacy Codeमेरी मेज :-)

— मार्टिन बा

0

Maven C ++ में व्यापक रूप से उपयोग नहीं किया जाता है (फिर भी, यह मुख्य रूप से जावा के लिए उपयोग किया जाता है, लेकिन भाषा अज्ञेयवादी है) लेकिन यह एक बहुत शक्तिशाली उपकरण है और यह आपको एक परियोजना में सब कुछ रखने की अनुमति देता है (परीक्षण सहित, वास्तव में, यह अनुशंसित है मावेन के साथ संपर्क)। मैं केवल इसे अभी से सुझाव देता हूं क्योंकि उत्तर से अब तक यह एक वीएस प्लगइन के साथ एक विकल्प के रूप में मौजूद नहीं हो सकता है।

मुझे मिले प्लगइन्स की खोज:

http://incubator.apache.org/npanday/

लेकिन यह अभी तक बहुत परिपक्व नहीं दिखता है। मावेन सेटअप के साथ mvn testकमांड लाइन में परीक्षण चलाने के लिए आपको बस इतना करना होगा ।

आप आप इसके बारे में जान सकते हैं रुचि रखते हैं, यहाँ और (में से एक) सी ++ प्लगइन्स समर्थन यहाँ (Maven तो सब कुछ एक प्लगइन है एक प्लगइन वास्तुकला है)।

— ज्ञान उर्फ गैरी ब्युन
स्रोत

0

फ्रेमवर्क अनुशंसा: हमारे कार्यालय में, हम TestDriven.NET का उपयोग करते हैं जो विज़ुअल स्टूडियो के साथ एकीकृत होता है। सबसे बेकार कक्षाएं C ++ / CLI में लिखी जाती हैं, जो तब बाहर निकालने के लिए कह सकते हैं कि आपको जो भी देशी कोड की परीक्षा देनी है। हां, C ++ / CLI वर्ग अपनी विधानसभा में जाते हैं, इस प्रकार समाधान के लिए एक "परीक्षण" परियोजना को जोड़ा जाता है।

— क्रिस ओ
स्रोत