Test Driven Development

Question: Discuss about the Test Driven Development. Answer: Introduction There is increasing effort to have the best software development process that results in software or IT project product that not only meets, but adds value to the customer through its outcomes/ effects. One of the development processes through which this can be achieved is through Test Driven Development (TDD); a process in which very short repetitive development cycles is relied on to develop the software. The requirements are converted into highly specific test cases; the software is then improved to pass only the new tests (Beck, 2014). This paper does some research on the TDD process and discusses how it works, its merits, possible downfalls, use, and prospects, before summarizing the findings Developed by Kent Beck around 2003, TDD is a relatively new process for software development. The cycle commences by the addition of a test; every new feature starts with writing a test that succinctly defines functions or function improvements (Beck, 2014). The developer must therefore fully understand the specifications and requirements of the feature and the tests can be achieved through user stories and use cases to define the exception conditions and the requirements. The test is written in any framework deemed suitable for the software environment. This approach makes the developer focus more on the requirements before sitting down to develop the code (Astels, 2003). After writing the tests, it is now time to run all the tests and observe whether the new test fails; this is done to authenticate whether the automated test framework is working correctly. It is also done to illustrate that the new test doesnt pass without needing new code since the required behavior exists already. This test also rules out possibility that the new test is faulty and will always pass the test. For expected reason, the new test should fail; this step is essential in increasing the confidence of the developer in the new test (Ga?rtner, 2013). After the test, the code is then developed that causes the test to be passed; the new written code is still imperfect and may just pass the test but this is acceptable since the code will be improved (Farcic, 2017) Tests are then run after the first code is written and all test cases have passed; at this point, the developer is confident the new or improved code will meet requirements of the test without breaking or degrading existing features. The new code has to be adjusted until it passes the tests in case it failed to pass the test (Farcic, 2017). The next step involves refactoring the code; the growing code must be regularly cleaned in TDD and it is advisable at this point to move new code to where it logically belongs from where it was convenient just to pass the tests. Duplication has to be removed and class, object, module, method, and variable must represent their present purpose and use clearly as extra functionality is added to it (Farcic, 2017). Objects can get larger and method bodies longer as new features are added; they benefit from their being split and their sum parts named carefully to improve maintainability and readability. This will be increasingly valuable at the later stages of the software development cycle. This stage of refactoring can also entail rearranging inheritance hierarchies to make them more helpful and logical and possible benefit from patterns that can be recognized easily. Tests are re-run continuously at every refactoring phase throughout the whole process, the coder can be confident that an y existing functionality is not being altered by the process. Duplication removal is a highly important process in software design and for TDD; it also enables removal of any duplication between the test and production codes (Ga?rtner, 2013). The next stage entails repeating the whole process, beginning with a new test cycle with the objective of pushing functionality forward. The size of the steps should remain small with between one and ten edits between every test run. If a new test is not satisfied rapidly by new code or there are unexpected fails in other tests, the coder needs to revert rather than engage in excessive debugging. Due to continuous integration, revertible checkpoints are provided and if external libraries are being used, increments that are very small as to be effective for only testing the library should be avoided unless the coder has reason to believe the library is not adequately feature rich or has bugs (Ambler, 2013), (Ga?rtner, 2013). Best practices requires test cases to be effectively laid out so all the requisite actions are completed while consistent structure aids in building test cases that are self-documenting. The test cases follow a structure of; Setup Execution Validation Cleanup (Ga?rtner, 2013). TDD Development Style TDD requires the units to be kept as small as possible; units in TDD are defined as a class or a module, which is a group of related functions. Keeping units small has several benefits, including reduced debugging effort since there are smaller units that help in quick tracking of errors during test failures; it also enables self-documenting tests since smaller test cases can be read and understood easily (Beck, 2014) It leads to high quality software developed in a shorter time and helps create elegant, simple modular software code. It allows developers to detect and remove bugs much earlier in the development process and the tests are live documentation that allows much easy reading and understanding of the code. In the long term, it speeds up development and ensures a more user centered software design as it enables developers to think from the users point of view rather than from a technical point of view (Hammell, 2005). A lot of effort and time is required upfront, especially writing the tests and because there is greater focus on small and simple designs at present times can result in significant refactoring requirements as the coder does not think ahead. In writing good tests, superfluous issues are also tested while maintaining a test suite requires time and effort. Due to rapid design changes, tests must change as rapidly as well ('MSDN', 2017). Future prospects TDD has gained considerable attention in the mainstream software development as a means for fast development of high quality software that is at par with the agile method. While having its share of critics, it has received widespread acclaim and the future prospects are bright, albeit with some refining and redefining of the process, especially the tests (Reese, n.d.). TDD is a relatively new concept in which software is developed through repetition of very short development cycles. The process entails adding a test, then running all the tests to see if there is fails for new tests before writing code. After the code is written, tests are run and the code refactored; the whole process is repeated before the software is considered complete. Its advantage is that it enables high quality software to be developed in a short time period while the main limitation is its seeming complexity in developing and running tests as design rapidly changes. References Ambler, S. (2013). Introduction to Test Driven Development (TDD). Agiledata.org. Retrieved 7 April 2017, from https://agiledata.org/essays/tdd.html Astels, D. (2003). Test-driven development (1st ed.). Upper Saddle River, N.J.: Prentice Hall PTR. Beck, K. (2014). Test-driven development (1st ed.). Boston [u.a.]: Addison-Wesley. Farcic, V. (2017). Test Driven Development (TDD): Example Walkthrough. Technology Conversations. Retrieved 7 April 2017, from https://technologyconversations.com/2013/12/20/test-driven-development-tdd-example-walkthrough/ Ga?rtner, M. (2013). ATDD by example (1st ed.). Upper Saddle River, NJ [u.a.]: Addison-Wesley. Hammell, T. (2005). Test-driven development: A J2EE example (1st ed.). Berkeley, Calif.: Apress. 'MSDN',. (2017). What are the Test Driven Development Disadvantages. Social.msdn.microsoft.com. Retrieved 7 April 2017, from https://social.msdn.microsoft.com/Forums/en-US/0893f9d2-fb5e-4172-8fd4-13d1b59b667f/what-are-the-test-driven-development-disadvantages?forum=architecturegeneral Reese, A. What is the future of test-driven development? - Our ComponentOne. Our ComponentOne. Retrieved 7 April 2017, from https://our.componentone.com/2014/05/05/what-is-the-future-of-test-driven-development/