DBUnit और स्प्रिंग टेस्टकोटेक्स्ट फ्रेमवर्क इंटीग्रेशन

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

एक सरल उदाहरण पर विचार करें: हमें डेटाबेस में एक डोमेन ऑब्जेक्ट के सही भंडारण का परीक्षण करने की आवश्यकता है।

@Entity public class Person { @Id @GeneratedValue(strategy = GenerationType.AUTO) private Long id; private String name; ... 

वस्तु को बचाने के लिए जिम्मेदार DAO:

 public class JpaPersonDao implements PersonDao { @PersistenceContext private EntityManager em; public void save(Person person) { em.persist(person); } } 

यह ध्यान देने योग्य है कि DAO एकीकरण परीक्षण में DAO, डोमेन ऑब्जेक्ट मैपिंग और दृढ़ता प्रदाता का व्यापक परीक्षण शामिल है। हमारे मामले में, हम हाइबरनेट का उपयोग बाद में करते हैं। परीक्षण के लिए, निम्न सामग्री के साथ स्प्रिंग संदर्भ testContext.xml बनाएं:

  <!--       @Transactional --> <tx:annotation-driven/> <!--     HSQLDB --> <jdbc:embedded-database id="dataSource" /> <!-- - --> <bean id="entityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean"> <property name="persistenceProviderClass" value="org.hibernate.ejb.HibernatePersistence"/> <property name="dataSource" ref="dataSource"/> <property name="packagesToScan" value="ru.kacit.commons.test.dbunit"/> <!-- ,      --> <property name="jpaPropertyMap"> <map> <entry key="hibernate.show_sql" value="true"/> <entry key="hibernate.format_sql" value="true"/> <entry key="hibernate.hbm2ddl.auto" value="create"/> </map> </property> </bean> <!--    --> <bean class="org.springframework.orm.jpa.JpaTransactionManager" id="transactionManager"> <property name="entityManagerFactory" ref="entityManagerFactory"/> </bean> <!--  DAO --> <bean class="ru.kacit.commons.test.dbunit.JpaPersonDao" /> 

अब JUnit के आधार पर ट्रांसेक्शनल परीक्षणों के लिए मानक स्प्रिंग टेस्ट कॉन्टेक्स्ट फ्रेमवर्क क्लास का विस्तार करके एक टेस्ट क्लास बनाते हैं। @ContextConfiguration एनोटेशन संदर्भ को इंगित करता है (स्थित, हमारे मामले में, क्लासपाथ में) जिसमें यह परीक्षण किया जाना चाहिए। यह @Autowired एनोटेशन का उपयोग करके हमें परीक्षण DAO इंजेक्षन करने की अनुमति देता है।

 @ContextConfiguration("classpath:testContext.xml") public class JunitDbunitTest extends AbstractTransactionalJUnit4SpringContextTests { @Autowired public PersonDao personDao; @Test public void test1() { personDao.save(new Person("")); personDao.save(new Person("")); personDao.save(new Person("")); } } 

बेस क्लास AbstractTransactionalJUnit4SpringContextTests को इस तरह से कॉन्फ़िगर किया गया है कि प्रत्येक परीक्षण पद्धति को एक लेनदेन में निष्पादित किया जाता है, जिसे विधि के अंत में वापस रोल किया जाता है।

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

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

स्प्रिंग द्वारा प्रदान की गई बेस टेस्ट कक्षाएं केवल टेस्ट बेस पर कुछ एसक्यूएल स्क्रिप्ट को निष्पादित करने की क्षमता प्रदान करती हैं। आइए देखें कि DBUnit हमारी मदद कैसे कर सकता है, और इसे स्प्रिंग टेस्टकोटेक्स्ट फ्रेमवर्क के साथ कैसे एकीकृत किया जा सकता है।

DBUnit आपको एक डेटाबेस की स्थिति का वर्णन करने की अनुमति देता है बिना भौतिक डेटा प्रकारों के बिना - एक XML डेटासेट के रूप में। यहां हमारे परीक्षण के लिए स्रोत डेटासेट है: यह खाली है, यह हमारे डोमेन वर्ग के अनुरूप एकमात्र व्यक्ति तालिका घोषित करता है।

 <!DOCTYPE dataset SYSTEM "dataset.dtd"> <dataset> <table name="person"> <column>id</column> <column>name</column> </table> </dataset> 

और यहाँ अपेक्षित डेटासेट है: व्यक्तियों की तालिका में तीन प्रविष्टियाँ हैं।

 <!DOCTYPE dataset SYSTEM "dataset.dtd"> <dataset> <table name="person"> <column>id</column> <column>name</column> <row> <value>1</value> <value></value> </row> <row> <value>2</value> <value></value> </row> <row> <value>3</value> <value></value> </row> </table> </dataset> 

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

आइए परीक्षण विधि के लिए एक एनोटेशन बनाएं, जो यह दर्शाता है कि विधि शुरू होने से पहले (विशेषता से पहले) कौन सा डेटासेट लोड किया जाना चाहिए, और इसके पूरा होने के बाद कौन सा डेटासेट डेटाबेस की जाँच करेगा (विशेषता के बाद):

 @Target(ElementType.METHOD) @Retention(RetentionPolicy.RUNTIME) public @interface DbunitDataSets { String before(); String after(); } 

इस एनोटेशन को संसाधित करने के लिए, हम मानक परीक्षण वर्ग AbstractTransactionalJUnit4SpringContextTests का विस्तार करते हैं।

 @TestExecutionListeners( AbstractDbunitTransactionalJUnit4SpringContextTests.DbunitTestExecutionListener.class ) public abstract class AbstractDbunitTransactionalJUnit4SpringContextTests extends AbstractTransactionalJUnit4SpringContextTests { /**  DBUnit */ private IDatabaseTester databaseTester; /**       */ private String afterDatasetFileName; /** ,      :   */ @AfterTransaction public void assertAfterTransaction() throws Exception { if (databaseTester == null || afterDatasetFileName == null) { return; } IDataSet databaseDataSet = databaseTester.getConnection().createDataSet(); IDataSet expectedDataSet = new XmlDataSet(ClassLoader.getSystemResourceAsStream(afterDatasetFileName)); Assertion.assertEquals(expectedDataSet, databaseDataSet); databaseTester.onTearDown(); } private static class DbunitTestExecutionListener extends AbstractTestExecutionListener { /** ,     :  */ public void beforeTestMethod(TestContext testContext) throws Exception { AbstractDbunitTransactionalJUnit4SpringContextTests testInstance = (AbstractDbunitTransactionalJUnit4SpringContextTests) testContext.getTestInstance(); Method method = testContext.getTestMethod(); DbunitDataSets annotation = method.getAnnotation(DbunitDataSets.class); if (annotation == null) { return; } DataSource dataSource = testContext.getApplicationContext().getBean(DataSource.class); IDatabaseTester databaseTester = new DataSourceDatabaseTester(dataSource); databaseTester.setDataSet( new XmlDataSet(ClassLoader.getSystemResourceAsStream(annotation.before()))); databaseTester.onSetup(); testInstance.databaseTester = databaseTester; testInstance.afterDatasetFileName = annotation.after(); } } } 

स्थिर नीडिंत वर्ग DbunitTestExecutionListener, TestContext ढांचे के हिस्से - श्रोता AbstractExecutionListener का विस्तार करता है। यह परीक्षण वर्ग पर एनोटेशन @TestExecutionListeners का उपयोग करके परीक्षण जीवन चक्र में शामिल है।

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

दूसरा प्रवेश बिंदु एसेटअटरट्रांसनेशन () विधि है, जो @AfterTransaction एनोटेशन के साथ चिह्नित है, जो TestContext फ्रेमवर्क का भी हिस्सा है। यह एनोटेशन यह सुनिश्चित करता है कि यह विधि @ ट्रान्सएक्टेंशियल एनोटेशन के साथ चिह्नित प्रत्येक परीक्षण विधि के लिए लेनदेन के अंत में निष्पादित होती है। इस पद्धति में, हम पहले से सहेजे गए डेटाबेसटैस्टर और afterDatasetFileName, साथ ही मानक DBUnit कार्यक्षमता का उपयोग करते हैं, डेटाबेस की स्थिति की अपेक्षा के साथ तुलना करने के लिए।

आइए देखें कि अब हमारी परीक्षा कैसी होगी:

 @ContextConfiguration("classpath:testContext.xml") public class JunitDbunitTest extends AbstractDbunitTransactionalJUnit4SpringContextTests { @Autowired private PersonDao personDao; @Test @Rollback(false) @DbunitDataSets(before = "initialDataset.xml", after = "expectedDataset.xml") @DirtiesContext public void test1() { personDao.save(new Person("")); personDao.save(new Person("")); personDao.save(new Person("")); } } 

एनोटेशन रोलबैक (गलत) परीक्षण के अंत में लेनदेन की पुष्टि प्रदान करता है। @DirtiesContext एनोटेशन वर्ग में अगले परीक्षण से पहले स्प्रिंग संदर्भ को फिर से बनाने की आवश्यकता को इंगित करता है। हमारे @DbunitDataSets एनोटेशन में, हमने प्रारंभिक और अपेक्षित DBUnor डेटासेट युक्त फ़ाइलों के नाम निर्दिष्ट किए हैं।

दिए गए परीक्षण मामले की सीमा प्रत्येक परीक्षण विधि से पहले वसंत संदर्भ को फिर से बनाने की आवश्यकता है। परीक्षण पूरा होने पर, डेटाबेस में न केवल कार्यशील डेटा होता है (जिसे DBUnit और AbstractTransactionalJUnit4SpringContextTests # deleteFromTables विधि) द्वारा आसानी से हटाया जा सकता है, लेकिन दृढ़ता प्रदाता के सहायक टेबल और अनुक्रम। इस प्रकार, प्रत्येक परीक्षण विधि को @DirtiesContext एनोटेशन के साथ चिह्नित किया जाना चाहिए। इस मामले में, प्रत्येक परीक्षण विधि से पहले, स्प्रिंग संदर्भ को फिर से बनाया जाएगा और डेटाबेस स्कीमा निर्यात किया जाएगा।

यह संभव है, संदर्भ को बढ़ाने में समय बर्बाद न करने के लिए, पहले हाइबरनेट योजना को फिर से निर्यात करने का प्रयास करें, फिर आप @DirtiesContext एनोटेशन के बिना कर सकते हैं। लेकिन मैंने ऐसा बेस टेस्ट क्लास में नहीं किया, सबसे पहले, ताकि इसे हाइबरनेट से न जोड़ा जाए। और फिर, डेटाबेस की इतनी सख्त सफाई भी कैशिंग जैसे सभी संभावित दुष्प्रभावों से छुटकारा पाने का भरोसा नहीं देगी।

अंत में, मैं यह नोट करना चाहता हूं कि TestNG पर आधारित एक अमूर्त परीक्षण उसी तरह से लिखा गया है और JUnit पर आधारित परीक्षण से अलग नहीं है, एक एक्सटेंसिबल बेस क्लास को छोड़कर - इस मामले में यह AbstractTransactorTestNGSpringContextTests होगा। अपने उद्देश्यों के लिए, मैंने DbunitTestExecutionListener श्रोता को एक अलग वर्ग में रखा और इन दो परीक्षण रूपरेखाओं के लिए दो आधार वर्गों को लागू किया।

लेख का स्रोत कोड GitHub पर पोस्ट किया गया है: github.com/forketyfork/spring-dao-test-demo