जावा में जेनेरिक का उपयोग कर कक्षा के लिए क्या यूनिट परीक्षण लिखना है?

Question

JpaDao वर्ग के बहुत विशिष्ट उदाहरण इस article में परिभाषित ले रहा है:

public abstract class JpaDao<K, E> implements Dao<K, E> { 
    protected Class<E> entityClass; 

    @PersistenceContext 
    protected EntityManager entityManager; 

    public JpaDao() { 
     ParameterizedType genericSuperclass = (ParameterizedType) getClass().getGenericSuperclass(); 
     this.entityClass = (Class<E>) genericSuperclass.getActualTypeArguments()[1]; 
    } 

    public void persist(E entity) { entityManager.persist(entity); } 

    public void remove(E entity) { entityManager.remove(entity); } 

    public E findById(K id) { return entityManager.find(entityClass, id); } 
} 

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

Answer 1

आप उन संस्थाओं के लिए एक सार परीक्षण कक्षा लिख ​​सकते हैं जो इसे उपclass।

उदाहरण के लिए:

public abstract class JpaDaoTest<K,E> { 

    abstract protected E getEntity(); 
    abstract protected JpaDao getDAO(); 

    @Test 
    public void testPersistCreatesEntity() 
    { 
     JpaDao dao = getDAO(); 
     dao.persist(getEntity()); 
     // assert 
    } 
} 

अनुबंध आप सामान्य वर्गों को लागू ऊपर यह सोचते हैं कि getEntity() सेट और रिलेशनल निर्भरता सही ढंग से बस के रूप में genericlly परीक्षण किया जाना, सक्षम होना चाहिए।

इसलिए, अपने जेनेरिक उप-वर्गों के लिए सभी परीक्षण मामलों के लिए इस टेस्ट क्लास को उप-वर्गीकृत करके, आपको नि: शुल्क परीक्षण मिलते हैं।

Answer 2

यदि किसी भिन्न इकाई प्रकार का उपयोग करने से अलग-अलग कोड निष्पादित होते हैं, तो आपको एक अलग परीक्षण केस की आवश्यकता होती है।

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

Answer 3

JUnit पूछे जाने वाले प्रश्न से:

4) मैं क्या स्थिति का परीक्षण करना चाहिए के तहत मिलता है() और सेट() पद्धतियों?

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

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

इसमें यह भी कहा:

"परीक्षण जब तक डर बोरियत में बदल जाता है।"

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

Answer 4

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

private <K, E> void testTypes(K k, E e) { 
    JpaDao<K, E> dao = new JpaDaoImpl<K, E>(); 

    dao.persist(e); 

    assertEquals(dao.getById(e.getId()).getClass(), e.getClass()); 
} 

@Test 
public void testIntegerAndOrder() { 
    this.<Integer, Order>testTypes(10, new Order()); 
} 

देखें, कोई बात नहीं क्या प्रकार K और E कर रहे हैं, दावे धारण करने के लिए उम्मीद कर रहे हैं (testIntegerAndOrder() विधि इस दावे को एक ठोस प्रकार मानों का उपयोग कर परीक्षण)।

यह, निश्चित रूप से, यूनिट परीक्षणों के संयोजन के साथ उपयोग किया जाना चाहिए, जो वास्तव में के कुछ विशेष प्रकार चर के मानों का परीक्षण कर रहे हैं। यह वही यूनिट परीक्षण होगा जो आप किसी भी जुनीट ट्यूटोरियल में पा सकते हैं। की नस में कुछ:

@Test 
public void testDao() throws Exception { 
    JpaDao<Integer, Order> dao = getDao(); 

    Order order = ...; 
    order.setId(10); 

    dao.persist(order); 

    assertEquals(order, dao.findById(10)); 
} 

देखें कि दावे के शब्दों यहां अलग: इस परीक्षण परीक्षण एक दावा है कि संग्रहीत वस्तु अपने आईडी चर आईडी की एक ठोस मूल्य, इससे पहले कि परीक्षण के रूप में नहीं प्रकार चर का उपयोग कर रखती है।

Answer 5

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

Answer 6

कंक्रीट वर्ग का परीक्षण बाद में इसे ओवरराइड करने की समस्या से बचें।

सामान्य परीक्षण करने के लिए यह सुंदर है लेकिन यह सुरक्षित नहीं है।

आप विकास के दौरान अधिकांश यूनिट टेस्ट कॉपी कर सकते हैं, और बाद में आप परीक्षण को कस्टमाइज़ कर सकते हैं।