{"id":161,"date":"2019-11-30T10:06:53","date_gmt":"2019-11-30T10:06:53","guid":{"rendered":"http:\/\/www.derniercriweb.solutions\/bury-blog\/?p=161"},"modified":"2024-12-05T10:55:17","modified_gmt":"2024-12-05T10:55:17","slug":"test-driven-development-cycle","status":"publish","type":"post","link":"https:\/\/www.derniercriweb.co.uk\/bury-blog\/2019\/11\/30\/test-driven-development-cycle\/","title":{"rendered":"Test Driven Development Cycle"},"content":{"rendered":"\n



1. Add a testIn test-driven development, each new feature begins with writing a test. Write a test that defines a function or improvements of a function, which should be very succinct. To write a test, the developer must clearly understand the feature’s specification and requirements. The developer can accomplish this through\u00a0use cases<\/a>\u00a0and\u00a0user stories<\/a>\u00a0to cover the requirements and exception conditions, and can write the test in whatever testing framework is appropriate to the software environment. It could be a modified version of an existing test. This is a differentiating feature of test-driven development versus writing unit tests\u00a0after<\/em>\u00a0the\u00a0code<\/a>\u00a0is written: it makes the developer focus on the requirements\u00a0before<\/em>\u00a0writing the code, a subtle but important difference.2. Run all tests and see if the new test failsThis validates that the\u00a0test harness<\/a>\u00a0is working correctly, shows that the new test does not pass without requiring new code because the required behaviour already exists, and it rules out the possibility that the new test is flawed and will always pass. The new test should fail for the expected reason. This step increases the developer’s confidence in the new test.3. Write the codeThe next step is to write some code that causes the test to pass. The new code written at this stage is not perfect and may, for example, pass the test in an inelegant way. That is acceptable because it will be improved and honed in Step 5.At this point, the only purpose of the written code is to pass the test. The programmer must not write code that is beyond the functionality that the test checks.4. Run testsIf all test cases now pass, the programmer can be confident that the new code meets the test requirements, and does not break or degrade any existing features. If they do not, the new code must be adjusted until they do.5. Refactor codeThe growing code base must be\u00a0cleaned up<\/a>\u00a0regularly during test-driven development. New code can be moved from where it was convenient for passing a test to where it more logically belongs.\u00a0Duplication<\/a>\u00a0must be removed.\u00a0Object<\/a>,\u00a0class<\/a>,\u00a0module<\/a>,\u00a0variable<\/a>\u00a0and\u00a0method<\/a>\u00a0names should clearly represent their current purpose and use, as extra functionality is added. As features are added, method bodies can get longer and other objects larger. They benefit from being split and their parts carefully named to improve\u00a0readability<\/a>\u00a0and\u00a0maintainability<\/a>, which will be increasingly valuable later in the\u00a0software lifecycle<\/a>.\u00a0Inheritance hierarchies<\/a>\u00a0may be rearranged to be more logical and helpful, and perhaps to benefit from recognized\u00a0design patterns<\/a>. There are specific and general guidelines for refactoring and for creating clean code.[6]<\/a><\/sup>[7]<\/a><\/sup>\u00a0By continually re-running the test cases throughout each refactoring phase, the developer can be confident that process is not altering any existing functionality.The concept of removing duplication is an important aspect of any software design. In this case, however, it also applies to the removal of any duplication between the test code and the production code\u2014for example\u00a0magic numbers<\/a>\u00a0or strings repeated in both to make the test pass in Step 3.RepeatStarting with another new test, the cycle is then repeated to push forward the functionality. The size of the steps should always be small, with as few as 1 to 10 edits between each test run. If new code does not rapidly satisfy a new test, or other tests fail unexpectedly, the programmer should\u00a0undo<\/a>\u00a0or revert in preference to excessive\u00a0debugging<\/a>.\u00a0Continuous integration<\/a>\u00a0helps by providing revertible checkpoints. When using external libraries it is important not to make increments that are so small as to be effectively merely testing the library itself,[4]<\/a><\/sup>\u00a0unless there is some reason to believe that the library is buggy or is not sufficiently feature-complete to serve all the needs of the software under development.

<\/p>\n\n\n

https:\/\/www.derniercriweb.co.uk<\/a>\nhttps:\/\/derniercri.biz<\/a>\nhttps:\/\/www.abportfolio.co.uk<\/a><\/pre>\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
1. Add a testIn test-driven development, each new feature begins with writing a test. Write a test that defines a function or improvements of a function, which should be very succinct. To write a test, the developer must clearly understand the feature’s specification and requirements. The developer can accomplish this through\u00a0use cases\u00a0and\u00a0user stories\u00a0to cover the […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[18],"tags":[21,23,25,20,19],"class_list":["post-161","post","type-post","status-publish","format-standard","hentry","category-computing","tag-bury","tag-greater-manchester","tag-radcliffe","tag-web-design","tag-web-development"],"_links":{"self":[{"href":"https:\/\/www.derniercriweb.co.uk\/bury-blog\/wp-json\/wp\/v2\/posts\/161","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.derniercriweb.co.uk\/bury-blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.derniercriweb.co.uk\/bury-blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.derniercriweb.co.uk\/bury-blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.derniercriweb.co.uk\/bury-blog\/wp-json\/wp\/v2\/comments?post=161"}],"version-history":[{"count":0,"href":"https:\/\/www.derniercriweb.co.uk\/bury-blog\/wp-json\/wp\/v2\/posts\/161\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.derniercriweb.co.uk\/bury-blog\/wp-json\/wp\/v2\/media?parent=161"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.derniercriweb.co.uk\/bury-blog\/wp-json\/wp\/v2\/categories?post=161"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.derniercriweb.co.uk\/bury-blog\/wp-json\/wp\/v2\/tags?post=161"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}