जावा में परीक्षण। स्पॉक फ्रेमवर्क

उदाहरण के रूप में JUnit और TestNG का उपयोग करते हुए पिछले लेखों में, मैंने परीक्षण-संचालित विकास (TDD) और डेटा-चालित परीक्षण (DDT) का उल्लेख किया। लेकिन एक और दृष्टिकोण है जो सक्रिय रूप से लोकप्रियता, व्यवहार-संचालित विकास (बीडीडी) प्राप्त कर रहा है। यह टीडीडी तकनीक का ऐसा विकास है, जिसमें परीक्षण को कुछ सिस्टम घटकों के परीक्षण के रूप में नहीं, बल्कि कार्यात्मक आवश्यकताओं के रूप में देखा जाता है। यदि टीडीडी परीक्षण या विधि जैसी अवधारणाओं का उपयोग करता है, तो बीडीडी के लिए यह एक विनिर्देश और आवश्यकताएं हैं। इस तकनीक के बारे में पहले से ही एक हब्र पर पहले ही बात की जा चुकी है:

• इकाई परीक्षण विकास
• चरम प्रोग्रामिंग, व्यवहार प्रेरित विकास और RSpec के साथ परिचित

यह दृष्टिकोण JUnit और TestNG दोनों का उपयोग करके लागू होता है। लेकिन विशेष रूप से BDD के लिए सिलवाया गया अन्य उपकरण हैं। इस लेख में मैं इस तरह के ढांचे के बारे में बात करूंगा। इसे स्पॉक फ्रेमवर्क कहा जाता है और न केवल बीडीडी के सिद्धांतों को जोड़ती है, बल्कि ग्रूवी के फायदे भी हैं। हां, हां, ग्रूवी। हालांकि ग्रूवी का उपयोग किया जाता है, इसका उपयोग जावा कोड का परीक्षण करने के लिए भी किया जाता है। उपयोग के उदाहरण स्प्रिंग, ग्रेल्स, टेपेस्ट्री 5 हैं। रुचि रखते हैं? फिर पढ़े।

व्यवहार-संचालित विकास

तो, मैं आपको याद दिलाता हूं कि यह क्या है। एक उदाहरण पर विचार करें। क्या कोई उपयोगिता है जो चींटी पैटर्न के साथ काम करती है (ये फाइलें लाने के लिए हैं)? - कोई 1 और केवल 1 वर्ण, * - किसी भी वर्ण की कोई भी संख्या, ** - कोई भी पथ। यह कुछ इस तरह दिखता है:

public abstract class PathUtils { public static boolean matchAntPath(final String path, final String pattern) { // ... } public static boolean matchAntPattern(final String path, final String pattern) { // ... } } 

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

 public class TestPathUtils extends Assert { @Test(dataProvider = "matchAntPatternData") public void testMatchAntPattern(final String pattern, final String text, final boolean expected) { final boolean actual = PathUtils.matchAntPattern(text, pattern); assertEquals(actual, expected); } @Test(dataProvider = "matchAntPathData") public void testMatchAntPath(final String pattern, final String path, final boolean expected) { final boolean actual = PathUtils.matchAntPath(path, pattern); assertEquals(actual, expected); } } 

शायद अपवादों को फेंके जाने पर गलत मापदंडों के परीक्षण को भी यहां जोड़ा जाएगा। अब इसे बीडीडी के दृष्टिकोण से देखते हैं।
एक परीक्षण सिर्फ एक परीक्षा नहीं है, बल्कि एक विनिर्देश है, और इसमें विधियों का नहीं, बल्कि आवश्यकताओं का समावेश है। PathUtils के लिए आवश्यकताओं को हाइलाइट करें :

• प्रतीक? टेम्पलेट की जाँच की जा रही स्ट्रिंग में किसी भी वर्ण के बराबर होनी चाहिए
• प्रतीक? टेम्पलेट चेक किए जाने वाले स्ट्रिंग में 1 और केवल 1 वर्ण के बराबर होना चाहिए
• पैटर्न में * चरित्र की जाँच की जा रही स्ट्रिंग में किसी भी वर्ण के बराबर होनी चाहिए
• पैटर्न में * चरित्र की जाँच की जाने वाली स्ट्रिंग के किसी भी वर्ण के बराबर होनी चाहिए
• टेम्प्लेट और स्ट्रिंग की जाँच किए जाने वाले मान शून्य नहीं होने चाहिए

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

 Given: PathUtils --- When: matchAntPattern(null, "some string") --- Then: NullPointerException should be thrown 

इस प्रकार, परीक्षण कुछ इस तरह दिखाई देगा:

 public class PathUtilsSpec extends Assert { @Test public void question_character_should_mean_any_character() { assertTrue(PathUtils.matchAntPattern("abb", "a?b")); assertTrue(PathUtils.matchAntPattern("a1b", "a?b")); assertTrue(PathUtils.matchAntPattern("a@b", "a?b")); assertTrue(PathUtils.matchAntPath("abb", "a?b")); assertTrue(PathUtils.matchAntPath("a1b", "a?b")); assertTrue(PathUtils.matchAntPath("a@b", "a?b")); // ... } @Test public void question_character_should_mean_only_one_character() { assertFalse(PathUtils.matchAntPattern("ab", "a?b")); assertFalse(PathUtils.matchAntPattern("aabb", "a?b")); assertFalse(PathUtils.matchAntPath("ab", "a?b")); assertFalse(PathUtils.matchAntPath("aabb", "a?b")); // ... } @Test public void asterisk_character_should_mean_any_character() { assertTrue(PathUtils.matchAntPattern("abb", "a*b")); assertTrue(PathUtils.matchAntPattern("a1b", "a*b")); assertTrue(PathUtils.matchAntPattern("a@b", "a*b")); assertTrue(PathUtils.matchAntPath("abb", "a*b")); assertTrue(PathUtils.matchAntPath("a1b", "a*b")); assertTrue(PathUtils.matchAntPath("a@b", "a*b")); // ... } @Test public void asterisk_character_should_mean_any_number_of_characters() { assertTrue(PathUtils.matchAntPattern("ab", "a*b")); assertTrue(PathUtils.matchAntPattern("aabb", "a*b")); assertTrue(PathUtils.matchAntPath("ab", "a*b")); assertTrue(PathUtils.matchAntPath("aabb", "a*b")); // ... } @Test public void double_asterisk_character_should_mean_any_path() { assertTrue(PathUtils.matchAntPath("aaa/bbb", "aaa/**/bbb")); assertTrue(PathUtils.matchAntPath("aaa/ccc/bbb", "aaa/**/bbb")); assertTrue(PathUtils.matchAntPath("aaa/c/c/c/bbb", "aaa/**/bbb")); // ... } } 

अब Spock फ्रेमवर्क के बारे में अधिक।

मुख्य विशेषताएं

जैसा कि मैंने कहा, ग्रूवी में स्क्रिप्ट लिखी जाती हैं। यह अच्छा है या बुरा? अपने लिए निर्णय लें, शुरुआती 15 मिनट में ग्रूवी पढ़ सकते हैं - एक त्वरित अवलोकन ।

विनिर्देश को spock.lang.Specification से विरासत में प्राप्त किया जाना चाहिए। इसमें फ़ील्ड्स, फ़िक्चर मेथड, फीचर स्क्रिप्ट, हेल्पर मेथड हो सकते हैं।

डिफ़ॉल्ट रूप से, फ़ील्ड स्क्रिप्ट के बीच साझा नहीं की जाती हैं, अर्थात एक परिदृश्य से फ़ील्ड परिवर्तन दूसरे परिदृश्य से दिखाई नहीं देगा। साझा करने के लिए, आप @ शेडिंग का उपयोग करके एनोटेट कर सकते हैं।

स्थापना के तरीके हैं:

• सेटअप () - JUnit में @Before का एनालॉग, प्रत्येक स्क्रिप्ट से पहले निष्पादित
• क्लीनअप () - JUnit में @After का एनालॉग, प्रत्येक स्क्रिप्ट के बाद निष्पादित
• setupSpec () - JUnit में @BeforeClass का एक एनालॉग, विनिर्देश में पहली स्क्रिप्ट से पहले निष्पादित
• CleanupSpec () - JUnit में @AfterClass का एनालॉग, विनिर्देश में अंतिम स्क्रिप्ट के बाद निष्पादित

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

आवश्यकता स्क्रिप्ट विनिर्देश का मुख्य भाग है। यह वह जगह है जहाँ घटक व्यवहार का वर्णन किया जाता है। यह स्ट्रिंग लिटरल्स का उपयोग करके उन्हें कॉल करने के लिए प्रथागत है, और आप किसी भी वर्ण का उपयोग कर सकते हैं, मुख्य बात यह है कि यह नाम जितना संभव हो उतना स्पष्ट रूप से वर्णन करता है कि यह स्क्रिप्ट क्या करती है। उदाहरण के लिए, हमारे मामले में:

 class PathUtilsSpec extends Specification { def "? character should mean any character"() { // ... } def "? character should mean only one character"() { // ... } def "* character should mean any character"() { // ... } def "* character should mean any number of characters"() { // ... } def "** character should mean any path"() { // ... } } 

प्रत्येक परिदृश्य में ब्लॉक होते हैं, जो लेबल द्वारा इंगित किए जाते हैं:

• सेटअप सेटअप () स्थापना विधि के समान है, केवल एक विशिष्ट परिदृश्य पर लागू होता है। शेष ब्लॉकों से पहले स्थित होना चाहिए और दोहराया नहीं जाना चाहिए। सेटअप लेबल गायब हो सकता है, आप सेटअप के बजाय दिए गए भी लिख सकते हैं, यह बेहतर पठनीयता के लिए किया जाता है (जब-तब-तब)
• क्लीनअप क्लीनअप () विधि के समान है, केवल एक विशिष्ट स्क्रिप्ट पर लागू होता है। स्क्रिप्ट के अंत में होना चाहिए जहाँ ब्लॉक से पहले, यदि कोई हो, और दोहराया नहीं जाना चाहिए
• जब-तब निष्पादन का कारण और शर्त है। जब भाग में, चर को आम तौर पर घोषित किया जाता है, तो आवश्यक कार्य किए जाते हैं, भाग में तब कुछ शर्तों की जाँच की जाती है। यह स्थितियों की जाँच, अपवाद के फेंकने की जाँच, या नकली वस्तुओं पर अमल करने के लिए कुछ तरीकों की प्रतीक्षा हो सकती है। इस ब्लॉक को दोहराया जा सकता है, लेकिन ढांचे के लेखक इसमें शामिल नहीं होने की सलाह देते हैं, एक अच्छी स्क्रिप्ट में 1 से 5 ऐसे ब्लॉक होने चाहिए
• अपेक्षा तब एक सरलीकृत है जब-तब ब्लॉक करें जहां कार्रवाई और सत्यापन एक ही अभिव्यक्ति में हैं
• जहाँ TestNG से @DataProvider का एक एनालॉग है, जिसे परीक्षण के लिए डेटासेट बनाने के लिए डिज़ाइन किया गया है

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

 public class PathSearcher { public PathSearcher(final String path) {...} public PathSearcher include(final String... patterns) {...} public PathSearcher exclude(final String... patterns) {...} public Set<String> search() {...} } 

हम आवश्यकता लिखते हैं "फ़ाइल सिस्टम पर फ़ाइलों की खोज करनी चाहिए":

 class PathSearcherSpec extends Specification { def "it should search files under the file system"() { given: def searcher = PathSearcher.create(inClasspath("test1")) when: def results = searcher.search(); then: results.containsAll(["1.txt", "2.txt"]); results.size() == 2 } private String inClasspath(path) { return ClassLoader.getSystemResource(path).toExternalForm() } } 

तो, यह दिया गया है - एक खोज इंजन जो क्लास 1 से टेस्ट 1 फ़ोल्डर में खोज करता है, खोज, निष्पादन स्थिति की जांच करता है - खोज इंजन को हमारी फाइलें ढूंढनी चाहिए। inClasspath एक सहायक विधि है जो classpath से निरपेक्ष फ़ाइल पथ लौटाती है।

PathUtils के लिए एक अन्य उदाहरण "टेम्पलेट के मूल्य और जाँच की जाने वाली स्ट्रिंग को अशक्त नहीं होना चाहिए"

 class PathUtilsSpec extends Specification { def "null parameter values are not allowed"() { when: PathUtils.matchAntPattern(null, "some string") then: thrown(NullPointerException) when: PathUtils.matchAntPattern("some string", null) then: thrown(NullPointerException) when: PathUtils.matchAntPath(null, "some string") then: thrown(NullPointerException) when: PathUtils.matchAntPath("some string", null) then: thrown(NullPointerException) } } 

यहां हम फेंका हुआ (...) तरीका देखते हैं, यह निर्दिष्ट अपवाद की अपेक्षा है, नोटट्रॉन (...) विधि और noExceptionThrown () भी है । उन्हें यह सत्यापित करना है कि कोई अपवाद नहीं दिया गया है। इसके अलावा तत्कालीन भाग में, नकली वस्तुओं के लिए कुछ तरीकों की अपेक्षाएं हो सकती हैं, लेकिन बाद में उनके बारे में अधिक। एक और उदाहरण:

 class PathUtilsSpec extends Specification { def "? character should mean any character"() { expect: PathUtils.matchAntPattern("abb", "a?b") PathUtils.matchAntPattern("a1b", "a?b") PathUtils.matchAntPattern("a@b", "a?b") PathUtils.matchAntPath("abb", "a?b") PathUtils.matchAntPath("a1b", "a?b") PathUtils.matchAntPath("a@b", "a?b") } } 

जैसा कि आप उदाहरण से देख सकते हैं, अगर कब और फिर दोनों हिस्सों को एक ही स्थिति में जोड़ा जा सकता है, तो उम्मीद ब्लॉक का उपयोग करना अधिक सुविधाजनक है। जहाँ ब्लॉक का उपयोग करके इसे परिचालनात्मक बनाकर इस परिदृश्य को बेहतर बनाया जा सकता है:

 class PathUtilsSpec extends Specification { def "? character should mean any character"() { expect: PathUtils.matchAntPattern(text, pattern) PathUtils.matchAntPath(text, pattern) where: pattern | text "ab?" | "abc" "ab?" | "ab1" "ab?" | "ab@" "a?b" | "abb" "a?b" | "a1b" "a?b" | "a@b" "?ab" | "aab" "?ab" | "1ab" "?ab" | "@ab" } } 

या तो:

 class PathUtilsSpec extends Specification { def "? character should mean any character"() { expect: PathUtils.matchAntPattern(text, pattern) PathUtils.matchAntPath(text, pattern) where: pattern << ["ab?", "ab?", "ab?", "a?b", "a?b", "a?b", "?ab", "?ab", "?ab"] text << ["abc", "ab1", "ab@", "abb", "a1b", "a@b", "aab", "1ab", "@ab"] } } 

या तो:

 class PathUtilsSpec extends Specification { def "? character should mean any character"() { expect: PathUtils.matchAntPattern(text, pattern) PathUtils.matchAntPath(text, pattern) where: [pattern, text] << [ ["ab?", "abc"], ["ab?", "ab1"], ["ab?", "ab@"], ["a?b", "abb"], ["a?b", "a1b"], ["a?b", "a@b"], ["?ab", "aab"], ["?ab", "1ab"], ["?ab", "@ab"] ] } } 

या इस तरह भी:

 class PathUtilsSpec extends Specification { def "? character should mean any character"() { expect: PathUtils.matchAntPattern(text, pattern) PathUtils.matchAntPath(text, pattern) where: [pattern, text] = sql.execute("select pattern, text from path_utils_test") } } 

मुझे लगता है कि उदाहरणों से सब कुछ स्पष्ट है, इसलिए मैं इस पर ध्यान केंद्रित नहीं करूंगा। मैं सिर्फ इस बात पर ध्यान देता हूं कि आप उस ब्लॉक में उन फ़ील्ड्स का उपयोग नहीं कर सकते जो @Sared के रूप में चिह्नित नहीं हैं।

बातचीत

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

  def dao1 = Mock(UserDAO) UserDAO dao2 = Mock() 

आप रिटर्न वैल्यू या ऐसी वस्तुओं के तरीकों को खुद से ओवरराइड कर सकते हैं। लेखक इस बातचीत को कहते हैं।

  dao1.findAll() >> [ new User(name: "test1", description: "Test User"), new User(name: "test2", description: "Test User"), new User(name: "test3", description: "Test User") ] dao2.findAll() >> { throw new UnsupportedOperationException() } 

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

 class UserCacheSpec extends Specification { def users = [ new User(name: "test1", description: "Test User"), new User(name: "test2", description: "Test User"), new User(name: "test3", description: "Test User") ] def "dao should be used only once for all user searches until invalidated"() { setup: def dao = Mock(UserDAO) def cache = new UserCacheImpl(dao) when: cache.getUser("test1") cache.getUser("test2") cache.getUser("test3") cache.getUser("test4") then: 1 * dao.findAll() >> users } } 

इस उदाहरण में, हम इस मॉक (सेटअप ब्लॉक) का उपयोग करके UserDAO के लिए एक नकली और एक वास्तविक UserCache ऑब्जेक्ट बनाते हैं । फिर हम नाम ( जब- ब्लॉक) के द्वारा कई उपयोगकर्ताओं को खोजते हैं और अंत में जाँचते हैं कि खोजा गया तरीका जो तैयार परिणाम देता है उसे केवल 1 बार कहा जाता है।
बातचीत का वर्णन करते हुए, आप टेम्प्लेट का उपयोग कर सकते हैं:

  1 * dao.findAll() >> users (1..4) * dao.findAll() >> users (2.._) * dao.findAll() >> users (_..4) * dao.findAll() >> users _.findAll() >> users dao./find.*/(_) >> users 

यहाँ और पढ़ें

अतिरिक्त विशेषताएं

जैसा कि आप देख सकते हैं, ढांचे में पहले से ही बहुत सारी विशेषताएं हैं। लेकिन अन्य रूपरेखाओं की तरह, कार्यक्षमता के विस्तार की संभावना है। उदाहरण अंतर्निहित एक्सटेंशन हैं:

• @ टाइमआउट - स्क्रिप्ट के लिए अधिकतम टाइमआउट सेट करता है, JUnit से @Test के टाइमआउट विशेषता का एक एनालॉग
• @Ignore - स्क्रिप्ट को निष्क्रिय करता है, JUnit से @Ignore का एनालॉग
• @IgnoreRest - एनोटेट को छोड़कर सभी स्क्रिप्ट को निष्क्रिय कर देता है, यदि आपको केवल 1 परीक्षण की आवश्यकता है तो उपयोगी है
• @FailsWith - अपेक्षित अपवाद, JUnit से @Test पर अपेक्षित विशेषता का एक एनालॉग सेट करता है
• @Unroll - इंगित करता है कि पैरामीटर स्क्रिप्ट को प्रत्येक पुनरावृत्ति के लिए अलग स्क्रिप्ट के रूप में निर्दिष्ट किया जाना चाहिए, यहां आप आवश्यकता नाम के लिए एक टेम्पलेट भी निर्दिष्ट कर सकते हैं, डिफ़ॉल्ट रूप से यह "#featureName [#iterationCount]" है

 class InternalExtensionsSpec extends Specification { @FailsWith(NumberFormatException) @Unroll("#featureName (#data)") def "integer parse method should throw exception for wrong parameters"() { Integer.parseInt(data) where: data << ["Hello, World!!!", "0x245", "1798237199878129387197238"] } @Ignore @Timeout(3) def "temporary disabled feature"() { setup: sleep(20000) } } 

अन्य ढांचे के साथ एकीकरण अलग-अलग मॉड्यूल में किए गए हैं:

• स्प्रिंग - विनिर्देश का उपयोग कर किया जाता है @ContextConfiguration (स्थान = "application_context_xml") और आश्रितों को @Autowired का उपयोग करके फ़ील्ड में इंजेक्ट किया जा सकता है
  
  

   @ContextConfiguration(locations = "context.xml") class SpringIntegrationSpec extends Specification { @Autowired String testSymbol def "test-symbol should be spring"() { expect: testSymbol == "spring" } } 

  
  
• Guice - विनिर्देश का उपयोग @UseModules (guice_module_class) के साथ किया जाता है और निर्भरताएँ @Inject का उपयोग करके फ़ील्ड में इंजेक्ट की जा सकती हैं
  
  

   public class GuiceModule extends AbstractModule { @Override protected void configure() { bind(String.class).annotatedWith(Names.named("test-symbol")).toInstance("guice"); } } @UseModules(GuiceModule) class GuiceIntegrationSpec extends Specification { @Inject @Named("test-symbol") String testSymbol def "test-symbol should be guice"() { expect: testSymbol == "guice" } } 

  
  
• टेपेस्ट्री - स्पेसिफिकेशन @SubModule (टेपेस्ट्री_मॉड्यूल_क्लास) का उपयोग करके एनोटेट किया जाता है और @ इंजेक्ट एनोटेशन का उपयोग करके निर्भरता को फ़ील्ड में इंजेक्ट किया जा सकता है
  
  

   public class TapestryModule { public void contributeApplicationDefaults(final MappedConfiguration<String, String> configuration) { configuration.add("test-symbol", "tapestry"); } } @SubModule(TapestryModule) class TapestryIntegrationSpec extends Specification { @Inject @Symbol("test-symbol") String testSymbol def "test-symbol should be tapestry"() { expect: testSymbol == "tapestry" } } 

  
  

अच्छी तरह से और सबसे महत्वपूर्ण बात, अगर आपको अपनी कार्यक्षमता की आवश्यकता है, तो आप अपने स्वयं के एक्सटेंशन जोड़ सकते हैं। कार्यक्षमता के विस्तार के लिए मुख्य वर्ग:

• IMethodInterceptor, IMethodInvocation विनिर्देशन विधियों के लिए पहला है। यह आपको विधि को कॉल करने से पहले और बाद में अपना कोड जोड़ने की अनुमति देता है। कार्य को सरल बनाने के लिए, आप AbstractMethodInterceptor वर्ग का उपयोग कर सकते हैं। दूसरा पहले से उपलब्ध है, मूल (अनुमानित) विधि के साथ काम करने के लिए कार्य करता है
• IGlobalExtension - आपको विनिर्देश मेटाडेटा ( SpecInfo ) के साथ काम करने की अनुमति देता है, यहां आप किसी भी विनिर्देश घटकों (फ़ील्ड्स, स्थापना विधियों, आवश्यकताओं स्क्रिप्ट) के लिए मेटाडेटा देख सकते हैं और अपने स्वयं के इंटरसेप्टर उन्हें जोड़ सकते हैं।
• IAnnotationDrivenExtension - पिछले वाले के समान, केवल कार्य को सरल करता है, यदि हमारा विस्तार एक विशिष्ट एनोटेशन से बंधा हुआ है, तो आप कार्य को सरल बनाने के लिए AbstractAnnotationDrivenExtension वर्ग का उपयोग कर सकते हैं

अपना स्वयं का एक्सटेंशन बनाने के लिए, आपको एक IGlobalExtension या IAnnotationDrivenExtension वंशज वर्ग बनाने की आवश्यकता होती है, जिसमें आपके IMethodInterceptor को विशेष रूप से विनिर्देश घटकों में जोड़ा जाएगा, और अंत में , मेटा एक्सटेंशन को META-INF / Services / org.spockframework.runtime.extension.IGlobal में जोड़ दें। , IAnnotationDrivenExtension के लिए, हमारे एनोटेशन को @ExtensionAnnotation (extension_class) का उपयोग करके एनोटेट करने की आवश्यकता है।
एक विस्तार का एक उदाहरण जो स्क्रिप्ट को कई बार निर्दिष्ट करता है:

 @Retention(RetentionPolicy.RUNTIME) @Target({ElementType.METHOD, ElementType.TYPE}) @ExtensionAnnotation(RepeatExtension.class) public @interface Repeat { int value() default 1; } public class RepeatExtension extends AbstractAnnotationDrivenExtension<Repeat> { @Override public void visitFeatureAnnotation(Repeat annotation, FeatureInfo feature) { feature.addInterceptor(new RepeatInterceptor(annotation.value())); } } public class RepeatInterceptor extends AbstractMethodInterceptor{ private final int count; public RepeatInterceptor(int count) { this.count = count; } @Override public void interceptFeatureExecution(IMethodInvocation invocation) throws Throwable { for (int i = 0; i < count; i++) { invocation.proceed(); } } } 

 class CustomExtensionsSpec extends Specification { @Repeat(10) def "custom extension"() { expect: Integer.parseInt("123") == 123 } } 

परीक्षण चल रहा है

इस तथ्य के कारण कि स्पॉक परीक्षण JUnit Launcher ( स्पुतनिक ) का उपयोग करके चलाए जाते हैं, वे विभिन्न आईडीई के तहत ठीक काम करते हैं (जैसा कि लेखक कहते हैं, मैंने केवल विचार के तहत जांच की)। आप चींटी, मावेन, ग्रेडेल से परीक्षणों के प्रक्षेपण को भी कॉन्फ़िगर कर सकते हैं। सेटिंग्स के बारे में सभी आवश्यक जानकारी यहां पाई जा सकती है ।
मैं अपने लिए यह जोड़ूंगा, मैंने मावेन के तहत विन्यास को थोड़ा बढ़ा दिया, क्योंकि लेखकों द्वारा प्रस्तावित maven3 के तहत काम नहीं किया। यहाँ मेरा विन्यास विकल्प है:

 <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelVersion>4.0.0</modelVersion> <parent> <groupId>com.example</groupId> <artifactId>testing-example</artifactId> <version>1.0-SNAPSHOT</version> </parent> <groupId>com.example</groupId> <artifactId>testing-spock</artifactId> <version>1.0-SNAPSHOT</version> <packaging>jar</packaging> <name>Testing Spock Framework Example</name> <description> This is an example application that demonstrates Spock Framework usage. </description> <dependencies> <dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>${groovy-version}</version> <scope>test</scope> </dependency> <dependency> <groupId>org.spockframework</groupId> <artifactId>spock-core</artifactId> <version>${spock.version}</version> <scope>test</scope> </dependency> </dependencies> <build> <testResources> <testResource> <directory>src/test/groovy</directory> </testResource> <testResource> <directory>src/test/resources</directory> </testResource> </testResources> <plugins> <plugin> <groupId>org.apache.maven.plugins</groupId> <artifactId>maven-surefire-plugin</artifactId> <configuration> <includes> <include>**/*Spec.groovy</include> </includes> </configuration> </plugin> <plugin> <groupId>org.codehaus.gmaven</groupId> <artifactId>gmaven-plugin</artifactId> <version>${gmaven-version}</version> <configuration> <providerSelection>${gmaven-provider}</providerSelection> </configuration> <executions> <execution> <goals> <goal>testCompile</goal> </goals> </execution> </executions> <dependencies> <dependency> <groupId>org.codehaus.groovy</groupId> <artifactId>groovy-all</artifactId> <version>${groovy-version}</version> </dependency> </dependencies> </plugin> </plugins> </build> <properties> <groovy-version>1.7.10</groovy-version> <gmaven-version>1.3</gmaven-version> <gmaven-provider>1.7</gmaven-provider> <spock.version>0.5-groovy-1.7</spock.version> </properties> </project> 

निष्कर्ष

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

उदाहरण यहां देखे जा सकते हैं ।

साहित्य

• व्यवहार-संचालित विकास
• व्यवहार चालक विकास
• मूल बातें