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

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

ठीक है, मैं, शायद सबसे प्रसिद्ध, और इसलिए सबसे अधिक इस्तेमाल किया जाने वाला परीक्षण ढांचा JUnit के साथ शुरू करूँगा। यह JUnit 3 और JUnit 4 के दो संस्करणों में उपयोग किया जाता है। मैं दोनों संस्करणों पर विचार करूंगा, क्योंकि पुराने प्रोजेक्ट्स में 3rd वन, जो जावा 1.4 का समर्थन करता है, अभी भी उपयोग किया जाता है।

मैं किसी भी मूल विचारों के लेखक होने का दिखावा नहीं करता, और शायद लेख में चर्चा की जाने वाली हर चीज परिचित है। लेकिन अगर आप अभी भी रुचि रखते हैं, तो बिल्ली का स्वागत करें।

जूनित ३

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

नोट: परीक्षण विधियाँ सार्वजनिक शून्य होनी चाहिए, स्थैतिक हो सकती हैं।

परीक्षणों में स्वयं कुछ कोड निष्पादित करने और जाँच करने के होते हैं। चेक को अक्सर एस्टर क्लास का उपयोग करके प्रदर्शन किया जाता है, हालांकि वे कभी-कभी एस्टर कीवर्ड का उपयोग करते हैं ।

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

public abstract class StringUtils { private static final int HI_BYTE_MASK = 0xf0; private static final int LOW_BYTE_MASK = 0x0f; private static final char[] HEX_SYMBOLS = { '0', '1', '2', '3', '4', '5', '6', '7', '8', '9', 'a', 'b', 'c', 'd', 'e', 'f', }; public static boolean isEmpty(final CharSequence sequence) { return sequence == null || sequence.length() <= 0; } public static String toHexString(final byte[] data) { final StringBuffer builder = new StringBuffer(2 * data.length); for (byte item : data) { builder.append(HEX_SYMBOLS[(HI_BYTE_MASK & item) >>> 4]); builder.append(HEX_SYMBOLS[(LOW_BYTE_MASK & item)]); } return builder.toString(); } } 

हम JUnit 3 का उपयोग करते हुए इसके लिए परीक्षण लिखेंगे। यह सबसे सुविधाजनक है, मेरी राय में, परीक्षण लिखने के लिए, एक वर्ग को एक ब्लैक बॉक्स के रूप में देखते हुए, इस वर्ग में प्रत्येक महत्वपूर्ण विधि के लिए एक अलग परीक्षण लिखें, इनपुट मापदंडों के प्रत्येक सेट के लिए कुछ अपेक्षित परिणाम। उदाहरण के लिए, isEmpty विधि के लिए एक परीक्षण:

  public void testIsEmpty() { boolean actual = StringUtils.isEmpty(null); assertTrue(actual); actual = StringUtils.isEmpty(""); assertTrue(actual); actual = StringUtils.isEmpty(" "); assertFalse(actual); actual = StringUtils.isEmpty("some string"); assertFalse(actual); } 

डेटा निर्माण को सेटअप विधि में स्थानांतरित करके आप डेटा और परीक्षण तर्क को अलग कर सकते हैं:

 public class StringUtilsJUnit3Test extends TestCase { private final Map toHexStringData = new HashMap(); protected void setUp() throws Exception { toHexStringData.put("", new byte[0]); toHexStringData.put("01020d112d7f", new byte[] { 1, 2, 13, 17, 45, 127 }); toHexStringData.put("00fff21180", new byte[] { 0, -1, -14, 17, -128 }); //... } protected void tearDown() throws Exception { toHexStringData.clear(); } public void testToHexString() { for (Iterator iterator = toHexStringData.keySet().iterator(); iterator.hasNext();) { final String expected = (String) iterator.next(); final byte[] testData = (byte[]) toHexStringData.get(expected); final String actual = StringUtils.toHexString(testData); assertEquals(expected, actual); } } //... } 

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

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

 public class StringUtilsJUnit3TestSuite extends TestSuite { public StringUtilsJUnit3TestSuite() { addTestSuite(StringUtilsJUnit3Test.class); addTestSuite(OtherTest1.class); addTestSuite(OtherTest2.class); } } 

आप एक ही टेस्ट को कई बार चला सकते हैं। ऐसा करने के लिए, रिपीटेडटेस्ट का उपयोग करें:

 public class StringUtilsJUnit3RepeatedTest extends RepeatedTest { public StringUtilsJUnit3RepeatedTest() { super(new StringUtilsJUnit3Test(), 100); } } 

ExceptionTestCase से टेस्ट क्लास का पालन करते हुए, आप अपवाद को फेंकने के लिए कुछ जाँच सकते हैं:

 public class StringUtilsJUnit3ExceptionTest extends ExceptionTestCase { public StringUtilsJUnit3ExceptionTest(final String name) { super(name, NullPointerException.class); } public void testToHexString() { StringUtils.toHexString(null); } } 

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

जूनित ४

जावा 5 से नई सुविधाओं के लिए समर्थन यहां जोड़ा गया था, अब एनोटेशन का उपयोग करके परीक्षण घोषित किए जा सकते हैं। इसी समय, फ्रेमवर्क के पिछले संस्करण के साथ पिछड़ी संगतता है, ऊपर चर्चा किए गए लगभग सभी उदाहरण यहां काम करेंगे ( रिपीटटेस्ट के अपवाद के साथ, यह नए संस्करण में नहीं है)।

तो क्या बदल गया है?

कुंजी एनोटेशन

एक ही उदाहरण पर विचार करें, लेकिन पहले से ही नई सुविधाओं का उपयोग कर:

 public class StringUtilsJUnit4Test extends Assert { private final Map<String, byte[]> toHexStringData = new HashMap<String, byte[]>(); @Before public static void setUpToHexStringData() { toHexStringData.put("", new byte[0]); toHexStringData.put("01020d112d7f", new byte[] { 1, 2, 13, 17, 45, 127 }); toHexStringData.put("00fff21180", new byte[] { 0, -1, -14, 17, -128 }); //... } @After public static void tearDownToHexStringData() { toHexStringData.clear(); } @Test public void testToHexString() { for (Map.Entry<String, byte[]> entry : toHexStringData.entrySet()) { final byte[] testData = entry.getValue(); final String expected = entry.getKey(); final String actual = StringUtils.toHexString(testData); assertEquals(expected, actual); } } } 

हम यहां क्या देखते हैं?

• काम को सरल बनाने के लिए, मैं एसेर वर्ग से विरासत में लेना पसंद करता हूं, हालांकि यह आवश्यक नहीं है।
• इससे पहले कि एनोटेशन उन तरीकों को इंगित करता है जिन्हें टेस्ट रन से पहले बुलाया जाएगा; विधियों को सार्वजनिक रूप से शून्य होना चाहिए। यहां, परीक्षण के लिए प्रीसेट आमतौर पर रखे जाते हैं, हमारे मामले में यह परीक्षण डेटा की पीढ़ी है ( setUpToHexStringData विधि)।
• @BeforeClass एनोटेशन उन तरीकों को दर्शाता है, जिन्हें परीक्षण वर्ग के तुरंत पहले बुलाया जाएगा, विधियों को सार्वजनिक स्थैतिक शून्य होना चाहिए। यह परीक्षण के लिए प्रीसेट रखने के लिए समझ में आता है जब कक्षा में विभिन्न प्रीसेट का उपयोग करके कई परीक्षण होते हैं, या जब कई परीक्षण एक ही डेटा का उपयोग करते हैं ताकि प्रत्येक परीक्षण के लिए समय बनाने में बर्बाद न करें।
• एनोटेशन के बाद संकेत मिलता है कि परीक्षण पूरा होने के बाद बुलाया जाएगा, तरीके सार्वजनिक शून्य होने चाहिए। यह वह जगह है जहां परीक्षण के बाद संसाधनों को जारी करने के संचालन को जारी किया जाता है, हमारे मामले में, परीक्षण डेटा को साफ करना ( आंसू की व्यवस्था करना )।
• @AfterClass एनोटेशन @BeforeClass से संबंधित है, लेकिन यह परीक्षण के बाद विधियों को निष्पादित करता है, जैसा कि @BeforeClass के मामले में, विधियों को सार्वजनिक स्थैतिक शून्य होना चाहिए।
• एनोटेशन टेस्ट का मतलब परीक्षण विधियों से है। पहले की तरह, इन विधियों को सार्वजनिक रूप से शून्य होना चाहिए। चेक यहां रखे गए हैं। इसके अलावा, इस एनोटेशन में दो पैरामीटर हैं, अपेक्षित - अपेक्षित अपवाद और टाइमआउट सेट करता है - उस समय को सेट करता है जिसके बाद परीक्षण विफल माना जाता है।

  @Test(expected = NullPointerException.class) public void testToHexStringWrong() { StringUtils.toHexString(null); } @Test(timeout = 1000) public void infinity() { while (true); } 

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

  @Ignore @Test(timeout = 1000) public void infinity() { while (true); } 

नियम

उपरोक्त सभी के अलावा, एक बल्कि दिलचस्प बात है - नियम। परीक्षण के लिए नियम एक प्रकार की उपयोगिताओं हैं जो परीक्षण से पहले और बाद में कार्यक्षमता को जोड़ते हैं।

उदाहरण के लिए, अस्थायी फ़ाइलों ( TemporaryFolder ), आदि के साथ काम करने के लिए अपेक्षित अपवाद ( ExpectedException ) सेट करने के लिए परीक्षण ( टाइमआउट ) के लिए समय -निर्धारित करने के लिए अंतर्निहित नियम हैं। एक नियम घोषित करने के लिए, आपको मेथड नियम से व्युत्पन्न प्रकार का एक सार्वजनिक गैर- स्थिर क्षेत्र बनाना होगा और इसे नियम का उपयोग करके एनोटेट करना होगा।

 public class OtherJUnit4Test { @Rule public final TemporaryFolder folder = new TemporaryFolder(); @Rule public final Timeout timeout = new Timeout(1000); @Rule public final ExpectedException thrown = ExpectedException.none(); @Ignore @Test public void anotherInfinity() { while (true); } @Test public void testFileWriting() throws IOException { final File log = folder.newFile("debug.log"); final FileWriter logWriter = new FileWriter(log); logWriter.append("Hello, "); logWriter.append("World!!!"); logWriter.flush(); logWriter.close(); } @Test public void testExpectedException() throws IOException { thrown.expect(NullPointerException.class); StringUtils.toHexString(null); } } 

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

Zapuskalki

लेकिन ढांचे की संभावनाएं खत्म नहीं होती हैं। कैसे शुरू होता है परीक्षण @RunWith का उपयोग करके भी कॉन्फ़िगर किया जा सकता है। इस स्थिति में, एनोटेशन में निर्दिष्ट वर्ग को रनर से विरासत में लिया जाना चाहिए। उन चौखटों पर विचार करें जो ढांचे के साथ ही आते हैं।

JUnit4 - डिफ़ॉल्ट लांचर , जैसा कि नाम से पता चलता है, JUnit 4 परीक्षण चलाने के लिए डिज़ाइन किया गया है।

JUnit38ClassRunner को JUnit 3 का उपयोग करके लिखे गए परीक्षणों को चलाने के लिए डिज़ाइन किया गया है।

सुइटमैथोड या ऑलस्टैट्स को जेयूनेट 3 टेस्ट चलाने के लिए भी डिज़ाइन किया गया है। पिछले लॉन्चर के विपरीत, यह क्लास एक स्टैटिक मेथड सूट के साथ पास की जाती है जिसमें टेस्ट (सभी टेस्ट का क्रम) वापस आ जाता है।

सुइट पिछले एक के बराबर है, केवल JUnit 4 परीक्षणों के लिए। @SuiteClasses एनोटेशन का उपयोग रनिंग टेस्ट को कॉन्फ़िगर करने के लिए किया जाता है।

 @Suite.SuiteClasses( { OtherJUnit4Test.class, StringUtilsJUnit4Test.class }) @RunWith(Suite.class) public class JUnit4TestSuite { } 

एनक्लोज्ड पिछले विकल्प के समान है, लेकिन एनोटेशन का उपयोग करने की सेटिंग के बजाय, सभी आंतरिक वर्गों का उपयोग किया जाता है।

श्रेणियां - श्रेणियों (समूहों) में परीक्षण आयोजित करने का प्रयास। ऐसा करने के लिए, श्रेणी को @ श्रेणी का उपयोग करके परीक्षणों को सौंपा गया है , फिर सुइट में परीक्षण योग्य श्रेणियों को कॉन्फ़िगर किया गया है। यह इस तरह लग सकता है:

 public class StringUtilsJUnit4CategoriesTest extends Assert { //... @Category(Unit.class) @Test public void testIsEmpty() { //... } //... } @RunWith(Categories.class) @Categories.IncludeCategory(Unit.class) @Suite.SuiteClasses( { OtherJUnit4Test.class, StringUtilsJUnit4CategoriesTest.class }) public class JUnit4TestSuite { } 

Parameterized एक बल्कि दिलचस्प लांचर है जो आपको पैरामीटर परीक्षण लिखने की अनुमति देता है। ऐसा करने के लिए, टेस्ट क्लास में एक स्टैटिक विधि घोषित की जाती है, जो डेटा की एक सूची लौटाती है, जिसे तब क्लास मेयर के तर्क के रूप में उपयोग किया जाएगा।

 @RunWith(Parameterized.class) public class StringUtilsJUnit4ParameterizedTest extends Assert { private final CharSequence testData; private final boolean expected; public StringUtilsJUnit4ParameterizedTest(final CharSequence testData, final boolean expected) { this.testData = testData; this.expected = expected; } @Test public void testIsEmpty() { final boolean actual = StringUtils.isEmpty(testData); assertEquals(expected, actual); } @Parameterized.Parameters public static List<Object[]> isEmptyData() { return Arrays.asList(new Object[][] { { null, true }, { "", true }, { " ", false }, { "some string", false }, }); } } 

सिद्धांत - पिछले एक के समान है, लेकिन परीक्षण विधि को पैरामीटर बनाता है, न कि निर्माता। डेटा @DataPoints और @DataPoint का उपयोग करके टैग किया गया है , और परीक्षण पद्धति को थ्योरी का उपयोग करके टैग किया गया है । इस कार्यक्षमता का उपयोग करने वाला एक परीक्षण कुछ इस तरह दिखाई देगा:

 @RunWith(Theories.class) public class StringUtilsJUnit4TheoryTest extends Assert { @DataPoints public static Object[][] isEmptyData = new Object[][] { { "", true }, { " ", false }, { "some string", false }, }; @DataPoint public static Object[] nullData = new Object[] { null, true }; @Theory public void testEmpty(final Object... testData) { final boolean actual = StringUtils.isEmpty((CharSequence) testData[0]); assertEquals(testData[1], actual); } } 

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

निष्कर्ष

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

उदाहरण गितुब पर पाए जा सकते हैं।

साहित्य

• JUnit
• 60 सेकंड में JUnit 4
• JUnit DataPoints और सिद्धांतों का उपयोग करना
• JUnit Parameterized एनोटेशन का उपयोग करना
• @Rule का उपयोग करके अपने खुद के JUnit एक्सटेंशन लिखना
• समवर्ती निष्पादन के लिए रनरसेक्यूलर के साथ शेड्यूलिंग जूनिट परीक्षण