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