{"id":944,"date":"2017-06-20T16:56:30","date_gmt":"2017-06-20T16:56:30","guid":{"rendered":"http:\/\/punjabirevolution.com\/?page_id=944"},"modified":"2017-06-20T17:24:31","modified_gmt":"2017-06-20T17:24:31","slug":"test-driven-development","status":"publish","type":"page","link":"http:\/\/punjabirevolution.com\/index.php\/test-driven-development\/","title":{"rendered":"Test Driven Development"},"content":{"rendered":"<h1>Test Driven Development<\/h1>\n<p>The first obvious question is, why it is called test driven development. Normally, we code&nbsp; first and then we write test cases for it using white box or black box testing techniques. So, in normal course of action, development drives testing. But, in test driven development, the test cases are written first before writing the code.<\/p>\n<h2>Why Test cases are written before coding?<\/h2>\n<p>In normal development, we may forget to write test cases after writing code. Some time, we may be lazy to write test cases and some time we may run short of time. But in test driven development, when we write the test case first, we may never forget to write the code. As the compiler will keep on giving out error unless we write the code for which the test had already been written. There are unit testing frameworks for almost all the high level languages. Let&rsquo;s see an example of Java.<\/p>\n<h2>Test Driven Development in Java using JUnit.<\/h2>\n<p>Java has many unit testing frameworks. The detail can be found at the following link.<br>\n<a href=\"https:\/\/en.wikipedia.org\/wiki\/List_of_unit_testing_frameworks#Java\">https:\/\/en.wikipedia.org\/wiki\/List_of_unit_testing_frameworks#Java<\/a><br>\nJUnit is the most famous. Let&rsquo;s use JUnit as an example. Suppose we are planning to write a class name MyCalc which would perform basic mathematical operation of addition, subtraction etc. But before writing that class, we would write the test class for it.<\/p>\n<pre class=\"lang:java decode:true \">package my_package;\r\nimport static org.junit.Assert.*;\r\nimport org.junit.Test;\r\n\r\npublic class MyCalcTest {\r\n\t@Test\r\n\tpublic void TestAdd() {\t\t\r\n\t\tMyCalc myCalc = new MyCalc();\r\n\r\n        int result = myCalc.add(5, 10);\r\n        assertEquals(15, result);\r\n\t}\r\n\t\r\n\t@Test \r\n\tpublic void TestSub(){\r\n\t\tMyCalc myCalc = new MyCalc();\r\n\r\n      \t  int result = myCalc.sub(50, 5);\r\n        \r\n        \tassertEquals(45, result);\r\n\t\t\r\n\t}\r\n}\r\n<\/pre>\n<p>Line 1: The testing in which this class is residing<br>\nLine2 &amp; 3: The imports required for testing<br>\nLine 6: @Test is annotation. Annotations in java have very special role. When we add annotation to a method, it changes the role of that method. In this example, the annotation, makes the method as test method. It means, the method will execute only in testing perspective. This method will never execute in normal execution of the application. It will only be executed when we would run the application in testing mode.<br>\nLine 7: The TestAdd is a test method for actual method Add().<br>\nLine 8: We created the object of the class under testing<br>\nLine 9: We call the method Add() by passing two arguments<br>\nLine 10: It is a method which is used to compare the actual results with expected results. AssertEqual compared two values. These values may be number, strings, floats or even arrays.There are also static asserting methods like assertTrue() assertFalse which can be used to compare the expected boolean values and actual outputs.<br>\nLine 14-20: Another testing method for actual method sub().<\/p>\n<p>So, we have successfully written a test class for some assumed actual class. The compiler would be given errors at lines 8,10, 16 and 18. To fix these errors, let&rsquo;s write the actual code.<\/p>\n<pre class=\"lang:java decode:true\">package my_package;\r\n\r\npublic class MyCalc {\r\n\t\r\n\tpublic int add(int a, int b)\r\n\t{\r\n\t\treturn a + b;\t\t\r\n\t}\t\r\n\tpublic int sub(int a, int b)\r\n\t{\r\n\t\treturn a-b;\t\t\r\n\t}\r\n}\r\n<\/pre>\n<h2>Java &ndash; JUnit example in Eclipse with screen shots<\/h2>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<h2>Java &ndash; JUnit example in NetBeans with screen shots<\/h2>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n<p>&nbsp;<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Test Driven Development The first obvious question is, why it is called test driven development. Normally, we code\u00a0 first and then we write test cases for it using white box or black box testing techniques. So, in normal course of action, development drives testing. But, in test driven development, the test cases are written first &hellip; <a href=\"http:\/\/punjabirevolution.com\/index.php\/test-driven-development\/\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;Test Driven Development&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"parent":0,"menu_order":0,"comment_status":"closed","ping_status":"closed","template":"","meta":[],"_links":{"self":[{"href":"http:\/\/punjabirevolution.com\/index.php\/wp-json\/wp\/v2\/pages\/944"}],"collection":[{"href":"http:\/\/punjabirevolution.com\/index.php\/wp-json\/wp\/v2\/pages"}],"about":[{"href":"http:\/\/punjabirevolution.com\/index.php\/wp-json\/wp\/v2\/types\/page"}],"author":[{"embeddable":true,"href":"http:\/\/punjabirevolution.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/punjabirevolution.com\/index.php\/wp-json\/wp\/v2\/comments?post=944"}],"version-history":[{"count":4,"href":"http:\/\/punjabirevolution.com\/index.php\/wp-json\/wp\/v2\/pages\/944\/revisions"}],"predecessor-version":[{"id":949,"href":"http:\/\/punjabirevolution.com\/index.php\/wp-json\/wp\/v2\/pages\/944\/revisions\/949"}],"wp:attachment":[{"href":"http:\/\/punjabirevolution.com\/index.php\/wp-json\/wp\/v2\/media?parent=944"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}