पीओजेओ

Question

के लिए जुनीट परीक्षण मैं एक परियोजना पर काम करता हूं जहां हमें अपने सभी साधारण बीन्स (पीओजेओ) के लिए यूनिट परीक्षण बनाना होता है। क्या पीओजेओ के लिए यूनिट टेस्ट बनाने का कोई मतलब है यदि उनमें से सभी में गेटर्स और सेटर हैं? क्या यह मानने के लिए एक सुरक्षित धारणा है कि पीओजेओ समय के लगभग 100% काम करेगा?

---

डुप्लिकेट की - Should @Entity Pojos be tested?

भी देखें

Is it bad practice to run tests on a DB instead of on fake repositories?

Is there a Java unit-test framework that auto-tests getters and setters?

Answer 1

टीडीडी में नियम "Test everything that could possibly break" एक गेटर ब्रेक कर सकता है? आम तौर पर नहीं, इसलिए मैं इसका परीक्षण करने के लिए परेशान नहीं हूं। इसके अलावा, कोड I परीक्षण निश्चित रूप से गेटर को कॉल करेगा ताकि परीक्षण किया जा सके।

मेरा निजी नियम यह है कि मैं किसी भी फ़ंक्शन के लिए एक परीक्षा लिखूंगा जो निर्णय लेता है, या एक छोटी गणना से अधिक बनाता है। मैं i+1 के लिए एक परीक्षण नहीं लिखूंगा, लेकिन शायद मैं if (i<0)... के लिए और निश्चित रूप से (-b + Math.sqrt(b*b - 4*a*c))/(2*a) के लिए होगा।

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

Answer 2

POJOs भी इस तरह के बराबर के रूप में अन्य कार्यों,() हो सकती है, hashCode(), तुलना करें(), और कई अन्य कार्यों। यह जानना उपयोगी हो सकता है कि वे कार्य सही तरीके से काम कर रहे हैं।

Answer 3

मुझे नहीं लगता कि सरल संपत्ति गेटर्स और सेटर्स का परीक्षण करने का एक बिंदु है। यूनिट-परीक्षण का बिंदु यह सत्यापित नहीं करना है कि आपका कंपाइलर काम करता है।

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

Answer 4

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

Answer 5

मेरा जवाब यह है कि छोटे गेटर्स और सेटर्स अपने स्वयं के परीक्षणों की योग्यता नहीं रखते हैं। यदि मैं सरल पढ़ने या लिखने के अलावा कोई कोड जोड़ता हूं, तो मैं परीक्षण जोड़ता हूं।

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

Answer 6

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

इसके अलावा, अगर पीओजेओ में कोई बग है तो मैं इसके लिए एक यूनिट टेस्ट तैयार करूंगा ताकि हम इसे फिर से होने से रोक सकें।

Answer 7

यह शायद वाकई

public void setX(int x) { 
    x = x; 
} 

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

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

Answer 8

यूनिट टेस्ट कोड जो आप चाहते हैं काम करता है (पाठ्यक्रम की जांच की स्थितियों के लिए)। यूनिट टेस्ट कोड न करें, आप केवल निश्चित काम करना चाहते हैं।

मैं ज्यादा नहीं सोच सकता कि मैं केवल इसके बारे में निश्चित होना चाहता हूं।

Answer 9

मैं एक बार कुछ इस तरह की वजह से दो घंटे बिताए:

int getX() 
{ 
    return (x); 
} 

int getY() 
{ 
    return (x); // oops 
} 

यह लगभग कोई समय सरल ही टिककर खेल के लिए परीक्षण लिखने के लिए ले जाता है, मैं इसे अब क्या आदत से बाहर के बाद से।

Answer 10

मैं कोड कवरेज के लिए कोबातुरा के साथ प्रयोग कर रहा हूं और बस एक ही मुद्दे पर आया।

कक्षा में जोड़ने के लिए एनोटेशन होना अच्छा लगेगा, जिसमें कहा गया था कि इस वर्ग को कोड कवरेज में शामिल न करें। हालांकि, अपने pojo को एक अलग पैकेज में रखना संभव है और फिर उस पैकेज को विश्लेषण से बाहर कर दें।

अपने उपकरण के आधार पर दस्तावेज़ीकरण देखें, यह चींटी, मेवेन या कमांड लाइन के साथ काम करता है।

Answer 11

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

Answer 12

मैंने अभी ऐसा करने के लिए एक प्रोजेक्ट शुरू किया है। यह अभी पूर्व-अल्फा चरण में है। यह एक ग्रहण प्लगइन है।

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

यह कोड-कवरेज रिपोर्ट के साथ भी मदद करता है, जो प्रबंधकों को खुश रखने में मदद करता है। (मेरी कंपनी एम्मा का उपयोग करती है)।

https://sourceforge.net/projects/unittestgplugin/

Answer 13

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

मैं समय की बर्बादी के रूप में डेटा स्टोर पीओजेओ पर यूनिट परीक्षणों को नहीं देखता, मैं उन्हें भविष्य के रखरखाव के लिए सुरक्षा नेट के रूप में देखता हूं। ऐसा कहा जा रहा है कि, यदि आप इन वस्तुओं को प्रमाणित करने के लिए मैन्युअल रूप से परीक्षण लिख रहे हैं, तो आप इसे कठिन तरीके से कर रहे हैं। http://gtcgroup.com/testutil.html

Answer 14

पर एक नज़र डालें, ओपन सोर्स यूटिलिटी http://meanbean.sourceforge.net/ है जो आपको POJO का परीक्षण करने की अनुमति देता है। एक ऐसा पृष्ठ भी है जो गुणों/प्रश्नों का वर्णन करता है जो इस उपयोगिता के प्रस्तावों पर हो सकते हैं और इसका उपयोग क्यों किया जाना चाहिए।

मैंने इसे कभी भी थक नहीं दिया है (अभी तक), लेकिन यह मेरी सिफारिश की गई है।

Answer 15

1. उपयोग पुस्तकालय: मौजूदा पुस्तकालयों का उपयोग करें जो POJO का परीक्षण करने में सहायता करते हैं। इस तरह की एक पुस्तकालय मैं आया था मतलब है।

   रेफरी: http://meanbean.sourceforge.net/

   Maven: http://mvnrepository.com/artifact/org.meanbean/meanbean (वर्तमान संस्करण: 2.0.3)

2. ध्यान न दें POJOs: सोनार POJOs या विशिष्ट संकुल बाहर करने के लिए विन्यस्त किया जा सकता इकाई से बाहर रखा जाना परीक्षण कवरेज रिपोर्ट। नीचे कुछ उदाहरण:

   <properties> 
       <sonar.coverage.exclusions> 
        **/domain/**/*, 
        **/pojos/* 
       </sonar.coverage.exclusions> 
   </properties> 
   

Answer 16

यह समस्या लंबोक पुस्तकालय जो यह सब बॉयलरप्लेट कोड समाप्त करने के साथ ही बराबर और hashCode का उपयोग करके हल किया जा सकता।

तो तुम जब तक आप बराबरी के लिए एक विशिष्ट आवश्यकता और hashCode

https://projectlombok.org/