कैसे सही ढंग से मुखर लिखने के लिए

अब बात करते हैं मुखरता की।

अभिकथन दी गई चीजों में से एक है, इसलिए यहां सब कुछ विशेषज्ञ प्रतीत होगा। कोई अंतर्निहित जावा या जुनिट का उपयोग करता है, कोई उन्नत पुस्तकालयों का उपयोग करता है, कोई अपना स्वयं का निर्माण करता है।

लेकिन इसे और अधिक गंभीरता से लेने की कोशिश करते हैं। कैसे, वास्तव में, ठीक है?

सबसे पहले, अभिकथन विनिर्देशन की नकल करते हैं। यदि विनिर्देशन चाहिए। रीटर्नवैलिडऑर्डर निर्दिष्ट किया जाता है, तो यह जांचा जाना चाहिए, न कि नोट करें।

दूसरी बात, अभिकथन को पढ़ना आसान होना चाहिए। यही है, विनिर्देश के साथ तुलना करते हुए, तुरंत।

यदि बहुत अधिक दावे हैं (मेरे चरम स्वाद में, एक से अधिक कई हैं, लेकिन हम कम से कम पांच से सात की सीमा लगाएंगे), तो परीक्षण समझ में आता है। अच्छे के लिए, प्रत्येक परीक्षा में गिरने का केवल एक कारण होना चाहिए।

परिसंपत्तियों को निर्देशित किया जा सकता है: एक आदिम क्षेत्र, वस्तु, संग्रह, शायद ही कभी एक समारोह या थंक।

वस्तु जितनी अधिक जटिल होगी, उतने ही जटिल और विविधतापूर्ण दावे होंगे, और उन्हें पढ़ना और त्रुटियों को ढूंढना उतना ही कठिन होगा।

सकारात्मक बयान दोहरे नकारात्मक लोगों की तुलना में बेहतर पढ़ते हैं।

कस्टम हेल्पर्स की तुलना में मानक तरीके बेहतर पढ़े जाते हैं। (कौन जानता है कि किसने और कहाँ सहायकों के पुस्तकालय का परीक्षण किया)। और दावे परीक्षण पद्धति के शरीर में होने चाहिए, न कि परीक्षण सहायकों के पीछे कहीं (सोनार सही रूप में कथनों की कमी पर कसम खाता है)।
फ़ील्ड्स के बारे में एसेट्स ऑब्जेक्ट्स के बारे में, और विशेष रूप से संग्रह के बारे में अधिक समझ में आते हैं।

नेस्टेड खेतों के मामले में, यह पूरी तरह से परीक्षण करने के लिए समझ में आता है।

नहीं

assertNotNull(order.getCustomer().getName) 

और

 assertNotNull(order) assertNotNull(order.getCustomer()) assertNotNull(order.getCustomer().getName()) 

Assers न केवल बेवकूफ़ तरीके से जाँचते हैं कि विधि से क्या लौटा है, बल्कि इसे प्रभावित करें। और अगर हम इसे बदल सकते हैं, तो हमें इसे बदलने की जरूरत है।

संग्रह के बारे में दावे करना अपेक्षाकृत कठिन है। क्या उनके पास शून्य हैं, क्या वे क्रमबद्ध हैं, वास्तव में वे कैसे क्रमबद्ध हैं, समानता के लिए तत्वों की जांच कैसे की जाती है, आदि। - यह सब संग्रह के लिए कठिन वस्तुओं को बनाता है, खासकर जब संग्रह के तत्वों से संबंधित विधि में तर्क होता है।

इसलिए, एक विधि की तरह:

 List<Order> getOrderList(List<OrderDao> orderDaoList){ return orderDaoList.stream().map(orderDao=>order.name(orderDao.getName).build()).collect(Collectors.toList()) } 

दो को विभाजित करना आसान है, एक ट्रांसफार्मर ऑर्डरडाउ => ऑर्डर करें और इसे अलग से परीक्षण करें, और दूसरा सार मैपर पर संग्रह की मैपिंग का परीक्षण करेगा, और हम इसे स्टब पर परीक्षण कर सकते हैं।

 List<Order> getOrderList(List<OrderDao> orderDaoList, OrderDaoToOrderMapper mapper){ return orderDaoList.stream().map(mapper::map).collect(Collectors.toList()) } 

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

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