ContactManager, भाग 3. MockMvc का उपयोग करके परीक्षण नियंत्रक

सभी को नमस्कार।

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

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

प्रोजेक्ट संरचना अद्यतन

सबसे पहले, लाइब्रेरी संस्करणों को अपडेट करें। स्प्रिंगफ्रैमवर्क को अब 3.2.1 संस्करण में अपडेट किया गया है, और इसमें प्रतिष्ठित MockMvc शामिल है, इसलिए यह अपडेट आवश्यक है। स्प्रिंग सुरक्षा थोड़ा पीछे है, लेकिन यह (लगभग) कोई समस्या नहीं है। हाइबरनेट संस्करण भी 4.1.9 तक बढ़ा। पूर्ण परियोजना फ़ाइल रिपॉजिटरी (लेख के अंत में लिंक) में मिल सकती है।

हाइबरनेट के संस्करण 4 में स्विच करने के लिए data.xml फ़ाइल के थोड़ा शोधन की आवश्यकता होती है। आपको संकुल नाम sessionFactory में 3 से 4 बदलने की जरूरत है, sessionFactory में configLocation और configurationClass मापदंडों को हटा दें और इसके बजाय configLocation पैरामीटर को जोड़ें, जहां हाइबरनेट मैपिंग से हाइबरनेट मैपिंग के साथ वर्ग पैकेजों की सूची स्थानांतरित करना है। इस फ़ाइल को स्वयं हटाया जा सकता है, हमें अब इसकी आवश्यकता नहीं है। परिणामस्वरूप, sessionfactory फॉर्म लेगी:

  <bean id="sessionFactory" class="org.springframework.orm.hibernate4.LocalSessionFactoryBean"> <property name="dataSource" ref="dataSource" /> <property name="packagesToScan"> <list> <value>net.schastny.contactmanager.domain</value> <value>com.acme.contactmanager.domain</value> </list> </property> <property name="hibernateProperties"> <props> <prop key="hibernate.show_sql">true</prop> <prop key="hibernate.hbm2ddl.auto">create-drop</prop> <prop key="hibernate.dialect">${jdbc.dialect}</prop> <prop key="hibernate.connection.charSet">UTF-8</prop> </props> </property> </bean> 

हमें परीक्षण संसाधनों की भी आवश्यकता होगी, इसलिए हम src/test/resources निर्देशिका बनाते हैं, उसमें security.xml testdb.properties security.xml सेटिंग्स कॉपी करते हैं, testdb.properties बनाते हैं - डेटाबेस के लिए गुण फ़ाइल। आप इसके बिना कर सकते हैं, लेकिन फिर से, शैक्षिक उद्देश्यों के लिए, हम देखेंगे कि आप बाहर से डिब्बे में गुण कैसे सेट कर सकते हैं। फ़ाइल सामग्री

 db.user.name=sa db.user.pass= 

भगवान जानता है क्या, लेकिन एक उदाहरण के रूप में, यह करेगा। हम log4j.xml प्रतिलिपि बनाते हैं और इस पर सभी संसाधनों के साथ। हम स्रोत कोड पास करते हैं।

src/test/groovy निर्देशिका, पैकेज com.acme.contactmanager.test

आदेश पंक्ति से असेंबली के दौरान हमारे खांचे परीक्षणों को खोजने के लिए, निर्माण-सहायक-मावेन-प्लगइन को pb.ml पर जोड़ें

परीक्षणों के लिए वसंत विन्यास

एक स्प्रिंग कॉन्फ़िगरेशन फ़ाइल बनाएँ TestConfig.groovy

 @Configuration @ComponentScan(['net.schastny.contactmanager.dao', 'com.acme.contactmanager.dao', 'net.schastny.contactmanager.web', 'net.schastny.contactmanager.service']) @PropertySource('classpath:testdb.properties') @ImportResource('classpath:security.xml') @EnableTransactionManagement class TestConfig { // ... } 

एनोटेशन के नाम अपने लिए बोलते हैं:

• यह कॉन्फ़िगरेशन है
• घटकों को निर्दिष्ट पैकेजों में देखा जाना चाहिए (याद रखें: ये खांचे हैं और सरणी को चौकोर कोष्ठक में संलग्न किया गया है)
• testdb.properties testdb.properties फ़ाइल लोड करने की आवश्यकता है
• security.xml बारे में मत भूलना। security.xml
• और हां, हमें लेनदेन की आवश्यकता होगी

वैसे, लेन-देन के संबंध में। DAO और सेवा वर्गों के लिए, इंटरफेस और कार्यान्वयन स्पष्ट रूप से अलग हो जाते हैं, लेकिन सामान्य तौर पर आप खुद को कार्यान्वयन वर्ग तक सीमित कर सकते हैं। इस स्थिति में, एनोटेशन में यह इंगित करना आवश्यक होगा कि प्रॉक्सीटार्ट स्वचालित रूप से बनाया गया है, अन्यथा समस्याएं @EnableTransactionManagement(proxyTargetClass = true) : @EnableTransactionManagement(proxyTargetClass = true)

अगला। testdb.properties से वर्ग विशेषताओं के साथ @Value गुण का उपयोग करके बाइंड गुण

 class TestConfig { @Value('${db.user.name}') String userName @Value('${db.user.pass}') String userPass // ... } 

LocalSessionFactoryBean जोड़ें, जहां हम प्राप्त गुणों का उपयोग करेंगे। यहां हम परिचित packagesToScan देखते packagesToScan

  @Bean public LocalSessionFactoryBean sessionFactory() { LocalSessionFactoryBean bean = new LocalSessionFactoryBean() bean.packagesToScan = [ 'com.acme.contactmanager.domain', 'net.schastny.contactmanager.domain'] as String[] Properties props = new Properties() props."hibernate.connection.driver_class" = "org.h2.Driver" props."hibernate.connection.url" = "jdbc:h2:mem:db1;DB_CLOSE_DELAY=-1;MVCC=TRUE;DB_CLOSE_ON_EXIT=FALSE" props."hibernate.connection.username" = userName props."hibernate.connection.password" = userPass props."hibernate.dialect" = "org.hibernate.dialect.H2Dialect" props."hibernate.hbm2ddl.auto" = "create-drop" props."hibernate.temp.use_jdbc_metadata_defaults" = "false" bean.hibernateProperties = props bean } 

यह बात hibernate.temp.use_jdbc_metadata_defaults = false तब मदद करती है जब यह डेटाबेस से मेटाडेटा प्राप्त करने के संदर्भ को धीमा कर देती है

और अंत में, हमारे विन्यास के "केक पर चेरी" HibernateTransactionManager होगा

  @Bean public HibernateTransactionManager transactionManager() { HibernateTransactionManager txManager = new HibernateTransactionManager() txManager.autodetectDataSource = false txManager.sessionFactory = sessionFactory().object txManager } 

मैं दोहराता हूं - xml पर आधारित परियोजना का विन्यास पुराना ही रहा है। यह कॉन्फ़िगरेशन केवल परीक्षणों पर लागू होता है।

परीक्षण शुरू करें

लेकिन यह सब एक कहावत थी, यह एक परी कथा का समय था। यह उम्मीद करना तर्कसंगत है कि MockMvc के साथ काम करने में 3 चरण होते हैं: एक नकली वस्तु का निर्माण, नियंत्रक को HTTP अनुरोध भेजना और वास्तव में परिणामों का विश्लेषण करना। पहले चरण के लिए - एक नकली वस्तु का निर्माण - हम WebApplicationContext के आधार पर एक बिल्डर का उपयोग करेंगे।

MockMvcTest.groovy नाम से एक वर्ग बनाएं

 @RunWith(SpringJUnit4ClassRunner.class) @WebAppConfiguration @ContextConfiguration(classes = [ TestConfig.class ] ) class MockMvcTest { @Autowired WebApplicationContext wac MockMvc mockMvc @Before public void setup() { this.mockMvc = MockMvcBuilders.webAppContextSetup(this.wac).dispatchOptions(true).build() } } 

अपमान करने के लिए सब कुछ सरल है। आप पहले से ही कुछ परीक्षण कर सकते हैं। हमारे नियंत्रक पर एक नज़र डालें और देखें कि home() विधि, जहां एक सरल पुनर्निर्देश है, एक परीक्षण परीक्षा के लिए एक अच्छा उम्मीदवार है।

  @RequestMapping("/") public String home() { return "redirect:/index"; } 

दरअसल, हम लिखते हैं

  @Test public void home() { MockHttpServletRequestBuilder request = MockMvcRequestBuilders.get("/") ResultActions result = mockMvc.perform(request) result.andExpect(MockMvcResultMatchers.redirectedUrl("/index")) } 

लगभग कोई स्पष्टीकरण आवश्यक नहीं है:

• MockMvcRequestBuilders.get ("/") का उपयोग करके हमें url के लिए GET अनुरोध के लिए एक रैपर मिलता है "/"
• mockMvc.perform (अनुरोध) परिणाम देता है
• परिणामस्वरूप, हम यह सत्यापित करते हैं कि इच्छित URL पर पुनर्निर्देशन वापस आ गया है

andExpect() फ़ंक्शन परिणाम की जाँच करने के लिए शानदार अवसर प्रदान करता है, यहाँ andExpect() उदाहरण हैं जो अपने काम का एक सामान्य विचार देते हैं:

 mockMvc.perform(get("/person/1")) .andExpect(status.isOk()) .andExpect(content().mimeType(MediaType.APPLICATION_JSON)) .andExpect(jsonPath("$.person.name").equalTo("Jason")); mockMvc.perform(post("/form")) .andExpect(status.isOk()) .andExpect(redirectedUrl("/person/1")) .andExpect(model().size(1)) .andExpect(model().attributeExists("person")) .andExpect(flash().attributeCount(1)) .andExpect(flash().attribute("message", "success!")); 

हम शुरू करते हैं, यह काम करता है। हुर्रे, पहला परीक्षण तैयार है। आगे क्या है? संपर्क सूची।

  @RequestMapping("/index") public String listContacts(Map<String, Object> map) { map.put("contact", new Contact()); map.put("contactList", contactService.listContact()); map.put("contactTypeList", contactService.listContactType()); return "contact"; } 

सभी समान GET अनुरोध, हम मापदंडों में मानचित्र प्राप्त करते हैं, इसे भरते हैं और नाम दृश्य वापस करते हैं। हम पहले से ही जानते हैं कि GET अनुरोध कैसे भेजें, यह केवल परिणाम की जांच को जोड़ने के लिए रहता है। हम एक दूसरी परीक्षा लिख ​​रहे हैं।

  @Test public void index() { ResultActions result = mockMvc.perform(MockMvcRequestBuilders.get("/index")) result.andExpect(MockMvcResultMatchers.view().name("contact")) .andExpect(MockMvcResultMatchers.model().attributeExists("contact")) .andExpect(MockMvcResultMatchers.model().attributeExists("contactList")) .andExpect(MockMvcResultMatchers.model().attributeExists("contactTypeList")) } 

फिर से, एक भी अतिरिक्त लाइन नहीं। अनुरोध पूरा करने के बाद, हमने नाम दृश्य की जाँच की, जिसे उसने हमें लौटा दिया, और जाँच की कि मॉडल के सभी गुण मौजूद हैं। इन विशेषताओं के अधिक विस्तृत अध्ययन के लिए, आप -Return () फ़ंक्शन का उपयोग करके वास्तविक MvcResult ऑब्जेक्ट का लिंक प्राप्त कर सकते हैं

 MvcResult mvcResult = result.andReturn() assert mvcResult.modelAndView.model.contactTypeList.size() == 3 

अब तक, सब कुछ ठीक चल रहा है, लेकिन अभी भी बहुत काम करना बाकी है। यह हमारी सूची में कुछ जोड़ने का समय है। नियंत्रक विधि इस तरह दिखती है:

  @RequestMapping(value = "/add", method = RequestMethod.POST) public String addContact(@ModelAttribute("contact") Contact contact, BindingResult result) { contactService.addContact(contact); return "redirect:/index"; } 

अंत में, पोस्ट विधि, प्लस अभी भी भयानक @ModelAttribute Contact contact पैरामीटर। लेकिन सब कुछ इतना बुरा नहीं है। "Mockmvc ModelAttribute" के लिए एक त्वरित Google खोज भी परिणाम देती है। इस तरह की मैपिंग को केवल क्वेरी मापदंडों के एक सेट से बदला जा सकता है। क्वेरी में पैरामीटर जोड़ने का कार्य इस तरह दिखने की अपेक्षा है: param(Stirng name, String... values) । हम लिखते हैं

  @Autowired ContactService contactService @Test public void add() { //      ,    def contacts = contactService.listContact() assert !contacts //         def contactTypes = contactService.listContactType() assert contactTypes //  POST-,      mockMvc.perform(MockMvcRequestBuilders.post("/add") .param("firstname",'firstname') .param("lastname",'lastname') .param("email",'firstname.lastname@gmail.com') .param("telephone",'555-1234') .param("contacttype.id", contactTypes[0].id.toString()) .andExpect(MockMvcResultMatchers.redirectedUrl("/index")) //    contacts = contactService.listContact() //        id assert contacts assert contacts[0].id //   ,      contactService.removeContact(contacts[0].id) } 

खैर, अंतिम विधि बनी हुई है - हटाएं ()।

  @RequestMapping("/delete/{contactId}") public String deleteContact(@PathVariable("contactId") Integer contactId) { contactService.removeContact(contactId); return "redirect:/index"; } 

@PathVariable करना कोई समस्या नहीं है, बस इसे URL में जोड़ें।

  @Test public void delete() { //     def contactTypes = contactService.listContactType() assert contactTypes Contact contact = new Contact( firstname : 'firstname', lastname : 'lastname', email : 'firstname.lastname@gmail.com', telephone : '555-1234', contacttype : contactTypes[0] ) contactService.addContact(contact) assert contact.id def contacts = contactService.listContact() //   contacts.id    id  assert contact.id in contacts.id //  POST- ,   URL id   // ${contact.id} -    placeholder,  GString! mockMvc.perform(MockMvcRequestBuilders.get("/delete/${contact.id}") .andExpect(MockMvcResultMatchers.redirectedUrl("/index")) // ,    def contacts = contactService.listContact() assert !(contact.id in contacts.id) } 

यह सब है, सभी विधियाँ स्वत: परीक्षण, चीयर्स से आच्छादित हैं! या चीयर्स नहीं? चौकस पाठक पूछेगा - सुरक्षा का क्या! यदि परीक्षण में उपयोगकर्ताओं और भूमिकाओं का उल्लेख नहीं है, तो हमने security.xml Xml को क्यों शामिल किया! और वह सही हो जाएगा। पाठ के तीसरे भाग में, हम स्प्रिंगसिक्योरिटी के साथ काम करने के लिए समर्थन जोड़ेंगे।

प्रमाणीकरण जोड़ें

यह मानना ​​तर्कसंगत है कि MockMvc को फ़िल्टर के साथ काम करने के लिए समर्थन होना चाहिए। वास्तव में, addFilter() में एक addFilter() विधि है, जिसमें हम springSecurityFilterChain का एक उदाहरण पारित कर सकते हैं। हमारे परीक्षण को निम्नानुसार बदलें:

  @Autowired FilterChainProxy springSecurityFilterChain @Before public void setup() { this.mockMvc = MockMvcBuilders.webAppContextSetup(this.wac) .addFilter(springSecurityFilterChain) //    .dispatchOptions(true).build() } 

अब हमारे पास url एक्सेस करते समय एक अधिकार जाँच है, लेकिन हमें किसी तरह सिस्टम में अपना परिचय देना होगा। चलो एक "मेरे कान के साथ feint" बनाने की कोशिश करें और सीधे SecirityContextHolder के लिए मूल्य निर्धारित करें।

  List<GrantedAuthority> authorities = AuthorityUtils.createAuthorityList("ROLE_USER"); Authentication auth = new UsernamePasswordAuthenticationToken("user1", "1111", authorities); SecurityContextHolder.getContext().setAuthentication(auth); 

यह विश्वसनीय लगता है, ऐड () पद्धति को निष्पादित करने का प्रयास करें, जिसके लिए ROLE_USER विशेषाधिकार की आवश्यकता होती है। Broads! यह काम नहीं किया

 DEBUG: org.springframework.security.web.access.intercept.FilterSecurityInterceptor - Secure object: FilterInvocation: URL: /add; Attributes: [ROLE_USER] DEBUG: org.springframework.security.web.access.intercept.FilterSecurityInterceptor - Previously Authenticated: org.springframework.security.authentication. AnonymousAuthenticationToken@d4551ca6: Principal: guest; Credentials: [PROTECTED]; Authenticated: true; Details: org.springframework.security.web.authentication. WebAuthenticationDetails@957e: RemoteIpAddress: 127.0.0.1; SessionId: null; Granted Authorities: ROLE_ANONYMOUS DEBUG: org.springframework.security.web.access.ExceptionTranslationFilter - Access is denied (user is anonymous); redirecting to authentication entry point 

Granted Authorities: ROLE_ANONYMOUS क्योंकि यह हमें संकेत देता है कि हमारे कानों के साथ हमारे Granted Authorities: ROLE_ANONYMOUS ने काम नहीं किया। लेकिन मैं आश्वस्त करने के लिए जल्दबाजी करता हूं - यहां हमारा कोई दोष नहीं है, सुरक्षा समर्थन अभी तक परीक्षणों में लागू नहीं किया गया है । यही कारण है कि शुरुआत में मैंने लिखा था कि स्प्रिंगसिटी के साथ एकीकरण "लगभग कोई समस्या नहीं है।" एक समस्या है, लेकिन यह हल करने योग्य है।

SecurityRequestPostProcessors.java वर्ग इसमें हमारी मदद करेगा। मैं इसकी सामग्री पर ध्यान केन्द्रित नहीं करूंगा, बस इसे src/test/java फ़ोल्डर में कॉपी करें और यह दिखाएं कि यह हमारी आवश्यकताओं में कैसे उपयोग किया जा सकता है।

हम setAuthentication(auth) को कॉल को हटा देते हैं जो बेकार हो गया है, और ऐड () पद्धति में हम अनुरोध संरचना में एक पंक्ति जोड़ते हैं:

  //... mockMvc.perform(MockMvcRequestBuilders.post("/add") .param("firstname",'firstname') .param("lastname",'lastname') .param("email",'firstname.lastname@gmail.com') .param("telephone",'555-1234') .param("contacttype.id", contactTypes[0].id.toString()) .with(SecurityRequestPostProcessors.userDetailsService("user1"))) //   Security .andExpect(MockMvcResultMatchers.redirectedUrl("/index")) // ... 

यही है, संक्षेप में, हम उपयोगकर्ता user1 की ओर से उनके सभी अधिकारों के साथ अनुरोध को निष्पादित करते हैं। और यह बहुत अच्छा काम करता है! लॉग में, हम वांछित Granted Authorities: ROLE_USER देखते हैं Granted Authorities: ROLE_USER

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

चलिए वापस ऐड () मेथड में आते हैं। जब हम अनधिकृत होते हुए संपर्क बनाए रखने की कोशिश करते हैं तो हमारा आवेदन क्या करता है? हमें लॉगिन पृष्ठ दिखाता है! एक रीडायरेक्ट के संदर्भ में, इसका मतलब /login.jsp पर पुनर्निर्देशित है
इसलिए, हम किसी अन्य के साथ संपर्क को बचाने के लिए अनधिकृत अनुरोध के परिणाम के सत्यापन की जगह लेते हैं:

 result.andExpect(MockMvcResultMatchers.redirectedUrl("http://localhost/login.jsp")) 

उसी तरह, हटाने () विधि को प्राधिकरण की अनुपस्थिति को लागू करना होगा। और उपयोगकर्ता "व्यवस्थापक" की ओर से, हटाने का काम करता है और यह सही है।

और यह एक अन्य विकल्प का परीक्षण करने के लिए बना हुआ है - जब अधिकारों के साथ एक उपयोगकर्ता ROLE_USER एक रिकॉर्ड को हटाने की कोशिश करता है। इस स्थिति में, उसे त्रुटि 403, या यों कहें कि /error403.jsp पर फ़ॉरवर्ड होना चाहिए। इस परिदृश्य के लिए परीक्षण विधि का शरीर इस तरह दिखेगा (संपर्क आईडी इस मामले में कोई फर्क नहीं पड़ता, बस सेट / 1):

  mockMvc.perform(MockMvcRequestBuilders.get("/delete/1") .with(SecurityRequestPostProcessors.userDetailsService("user1"))) .andExpect(MockMvcResultMatchers.forwardedUrl("/error403.jsp")) 

वह सब है। नतीजतन, हमें 12 परीक्षण विधियां मिलीं, प्रत्येक में 4 में से 3 यूआरएल। वे अनधिकृत पहुंच, अधिकारों के साथ पहुंच की जांच करते हैं और ROLE_USER और ROLE_ADMIN। नियंत्रकों के साथ, हमने सेवाओं और डीएओ के तरीकों का परीक्षण किया।

GitHub प्रोजेक्ट सोर्स कोड