{"id":1319,"date":"2021-03-04T11:58:45","date_gmt":"2021-03-04T10:58:45","guid":{"rendered":"http:\/\/mateuszglowinski.pl\/?p=1319"},"modified":"2021-03-04T16:03:04","modified_gmt":"2021-03-04T15:03:04","slug":"test-driven-development","status":"publish","type":"post","link":"https:\/\/mateuszglowinski.pl\/index.php\/2021\/03\/04\/test-driven-development\/","title":{"rendered":"Test Driven Development"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t

What is Test Driven Development (TDD)?<\/h4>

Test Driven Development (TDD) refers to programminmg style, where feature development starts with coding a test. Once we have a failing test (this is necessary requirement, because we still don’t have a feature implemented) we proceed with feature development.<\/p>

Test driven development phases<\/span><\/span><\/h4>

TDD consists of 3 phases:<\/p>

      1. red (name comes from failing test)<\/li>
      2. green (name\u00a0 comes from passing test)<\/li>
      3. refactor<\/li><\/ol><\/li><\/ol><\/li><\/ol>

        Those 3 phases are creating a cycle, which lead us to working feature with high-quality code.<\/p>

        \"\"<\/p>

        During TDD development can be a few cycles. Unit test does not have to be fully prepared at the beginning in red phase in first cycle, but can be extended\u00a0 during second cycle or even in later onces.<\/p>

        Phase 1 (Green)<\/h5>

        We must always start our work in TDD with this phase. It is important to remember that the test defining a future test should be failing. When you think about it, it is obvious becaue we don’t have feature implemented yet or we are just before updating the code.<\/p>

        It might also be, that code will not compile e.g. due to some missing methods.<\/p>

        Phase 2 (Red)<\/h5>

        Next step is to develop a feature itself. The code does not need to be perfect, it only has to make the test passed.<\/p>

        Once it is ready, we should run not only test for our feature, but all the units tests. In this case we make sure, that our changes did not break anything.<\/p>

        Phase 3 (Refactor)<\/h5>

        In this phase, we refactor our code. The code should be as minimal as possible to make the unit test passed.<\/p>

        It is required to run all unit tests at the end of this phace, to make sure that refactoring did not break application.<\/p>

        TDD usage example<\/h4>

        Let’s say we want to manage children class in school. As a beginning, we were told to prepare a feature to involve and count children in class.<\/p>

        Cycle 1<\/h5>

        As described above,\u00a0 the proces of development should be started with failing test (phase red). Let’s think what we need. After a while we came to the point that<\/span><\/span> we need class for representing a school class.<\/p>

        package org.app.controller;\nimport org.junit.jupiter.api.Test;\n\npublic class SchoolClassTest {\n\n    @Test\n    void shouldBeAbleToAddContactToBook() {\n\n        SchoolClass schoolClass = new SchoolClass();\n\n    }\n\n}\n<\/pre>
        It is important, that the test is failing in this phase.<\/p>
        \"\"<\/p>
        Once we have the test prepared, we can go to phase 2 (green).\u00a0 To make the test passed, we simply need to create class SchoolClass<\/em>.<\/p>
        package org.app.controller;\n\npublic class SchoolClass {\n}\n<\/pre>
        It is enough to have the test passing, that is why we don’t need more code for now.<\/p>
        \"\"<\/p>
        Once the test passed, we are done with phase 2 (green).<\/p>
        Phase 3 (refactor) can be skipped in this cycle, because there is nothing to refactor. It means that we are done with first cycle and we can go with second cycle. Let’s develop further the test.<\/p>
        Cycle 2<\/h5>
        package org.app.controller;\nimport org.junit.jupiter.api.Test;\n\npublic class SchoolClassTest {\n\n    @Test\n    void shouldBeAbleToAddChildrenToSchoolClass() {\n\n        SchoolClass schoolClass = new SchoolClass();\n        schoolClass.addChild(\"Jack\");\n\n    }\n\n}\n<\/pre>
        The test will fail now, because SchoolClass<\/em> does not have addChild<\/em> method implemented.<\/p>
        Let’s add now addChild<\/em> method in SchoolClass<\/em>:<\/p>
        package org.app.controller;\n\npublic class SchoolClass {\n\n    public void addChild(String childName) {\n\n    }\n\n}\n<\/pre>
        Notice that there is addChild<\/em> method defined, but body of it is empty. It has to be like that, because it is enough to make the test pass.<\/p>
        Phase 3 (refactor) also in this cycle can be skipped, because there is no need for refactoring.<\/p>
        Cycle 3<\/h5>
        Let’s start third cycle.<\/p>
        package org.app.controller;\nimport org.junit.jupiter.api.Test;\nimport org.junit.jupiter.api.Assertions;\n\npublic class SchoolClassTest {\n\n    @Test\n    void shouldBeAbleToAddChildrenToSchoolClass() {\n\n        SchoolClass schoolClass = new SchoolClass();\n        schoolClass.addChild(\"Jack\");\n\n        Assertions.assertEquals(schoolClass.getChildrenNumber(), 1);\n    }\n\n}\n<\/pre>
        As you can see, the test is now fully ready to check the functionality of adding a child to the class.<\/p>
        Test is failing, so we are ready to go to phase 2.<\/p>
        package org.app.controller;\n\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class SchoolClass {\n    \n    private List childrenList = new ArrayList<>();\n\n    public void addChild(String ChildName) {\n        childrenList.add(ChildName);\n    }\n\n    public int getChildrenNumber() {\n        return childrenList.size();\n    }\n\n}\n<\/pre>
        The test is passing, so the whole concept of functionality is working fine<\/p>
        Next phase is refactoring. Parameter ChildName<\/em> in addChild<\/em> method does not meet Java convention, that is why small correction is needed.<\/p>
        package org.app.controller;\n\nimport java.util.ArrayList;\nimport java.util.List;\n\npublic class SchoolClass {\n    \n    private List childrenList = new ArrayList<>();\n\n    public void addchild(String childName) {\n        childrenList.add(childName);\n    }\n\n    public int getChildrenNumber() {\n        return childrenList.size();\n    }\n\n}\n<\/pre>
        That would be it. Add children to school class functionallty is ready and unit test for checking that is also there.<\/p>
        Why to use TDD?<\/h4>
        TDD forces developers to define clear goal and think about the code . Thanks to that, there is a clear view on what we need to implement.<\/p>
        Moreover, the code is immediately tested within our needs and therefore less buggy. <\/span><\/span><\/p><\/div>\n\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t","protected":false},"excerpt":{"rendered":"
        What is Test Driven Development (TDD)? Test Driven Development (TDD) refers to programminmg style, where feature development starts with coding a test. Once we have…<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":[],"categories":[33],"tags":[],"_links":{"self":[{"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/posts\/1319"}],"collection":[{"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/comments?post=1319"}],"version-history":[{"count":68,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/posts\/1319\/revisions"}],"predecessor-version":[{"id":1404,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/posts\/1319\/revisions\/1404"}],"wp:attachment":[{"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/media?parent=1319"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/categories?post=1319"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mateuszglowinski.pl\/index.php\/wp-json\/wp\/v2\/tags?post=1319"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}