Name of the paper: Effective Development and Testing using TDD. Name of Project Teams: Conversion Team and Patient Access Team.

Transcription

1 1 Name of the paper: Effective Development and Testing using TDD Name of the author: Payal Sen Id: Contact Number: Name of Project Teams: Conversion Team and Patient Access Team.

2 2 Abstract Test Driven Development (TDD) is a software development practice in which acceptance test cases are incrementally written prior to code implementation. In this paper I like to share how TDD has become one of the best practices for us and how using automated TDD based tool DART (Database Automated Regression Tester) in our project has produced higher quality code. In our project Conversion, Conversion of Data from a legacy system (Account based) to a modern HIS (Health Information System) system which is Encounter based requires a web of complex data transformations. To this effect the number of business logic implemented in the conversion suite runs into thousands. Hence any modification can undergo hundreds of regression test. Doing this manually is highly error prone. Hence a tool based regression test and a test driven development is the need of the hour to ensure quality deliverables. My practical observation supports that TDD has the potential of increasing the level of testing in the industry as testing as an integral part of code development. Introduction Test Driven Development (TDD), a software development practice used periodically for decades has gained added visibility recently as a practice of Extreme Programming (XP).TDD is also known by names such as, Test First Design (TFD), Test First Programming (TFP) and Test Driven Design (TDD). The practice evolves the design of a system starting from the acceptance test cases of an object. Writing test cases and implementing that object or object methods then triggers the need for other objects/methods. An important rule in TDD is: If you can t write test for what you are about to code, then you shouldn t even be thinking about coding. [1] Test-Driven Development With TDD, before writing implementation code, the developer writes automated acceptance test cases for the new functionality they are about to code. After writing test cases that generally will not even compile, the developers write implementation code to pass these test cases. The developer writes a few test cases, implements the code, writes a few test cases, implements the code, and so on. The work is kept within the developer s intellectual control because he or she is continuously making small design and implementation decisions and increasing functionality at a relatively consistent rate. A new functionality is not considered properly implemented unless these new acceptance test cases and every other acceptance test cases ever written for the code base run properly. The motto of test-driven development is "Red, Green, Refactor." Red: Create a test and make it fail. Green: Make the test pass by any means necessary. Refactor: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass. The Red/Green/Refactor cycle is repeated very quickly for each new unit of code.

3 3 Figure 1 shows Steps of TDD. Fig1: Steps of TDD Intellectually, one can consider why TDD could be superior to other approaches. In any process, there exists a gap between decision (design developed) and feedback (performance obtained by implementing that design). The success of TDD can be attributed to the lowering, if not elimination, of that gap, as the granular testthen-code cycle gives constant feedback to the developer [2]. As a result, defects and cause of the defect can be easily identified the defect must lie in the code that was just written or in code with which the recently added code interacts. An often- cited tenet of Software Engineering, in concert with the Cost of Change [3], is that the longer a defect remains in a software system the more difficult and costly it is to remove. With TDD, defects are identified very quickly and the source of the defect is more easily determined. Hence it is this higher granularity of TDD that differentiates the practice from other testing and development models. TDD entices programmers to write code that is automatically testable, such as having functions/methods/stored procedures returning a value which can be checked against expected results. Benefits of automated testing include: Production of a reliable system, Improvement of the quality of the test effort, and Reduction of the test effort and minimization of the schedule

4 4 The TDD test case create a through regression test bed. By continuously running these automated test cases, one can easily determine if a new change breaks anything in the existing system. This test bed should also allow smooth integration of new functionality into the code base. DART - Database Automated Regression tester DART is an automated regression test framework designed to support Acceptance Testing. It is UI based tool. It has DB Connections ability to re-point DART to different DB servers and database. UI Tweaks resizing and display of a plan s Test Plan profile & DB version Fixed load of Backup DBs Added Build Configuration Validation The DART Tool is used validate the business rule that we apply through coding. It provides the platform to create the input as well as expected output scenarios as per the business rule. After running the Dart tool with the inputs and the updated code, it will let us know if the expected result is matching to the actual result. If the result matches then it shows status as Status: Passed against the validate queries and if mismatch then it show status as Status: Failed. If all test cases pass, the programmer can be confident that the code meets all the tested requirements.

5 5 DART Functionality Fig 2: Dart Tool Left plane of the DART Tool shows the list of Acceptance Tests. The upper right plane gives of DB Connection and Build information. The middle plane displays the Plan Details of the Acceptance Tests. The Lower plane is the one that executes the Acceptance Test. By default it contains 5 tabs: SetUp: Clear down the transaction data keeping only the master data in the database. Create Database Inputs: Create the environment such that data already exist in Soarian as per the Acceptance Test requirement. Incoming input files: This can be the tab that processes the input file. For my case it is HL7 file or WX file (Demographics or Financials) depending on which conversion event is being executed. Execute Conversion: This tab runs the series of Stored Procedures required for Conversion execution Validation Results: This is the prime tab that reveals finally if the code written for the Acceptance Test fully adheres to the business requirement. If yes then the expected query and result set will show status as Passed else it will show the status as Failed. Clean Up: Revert back any changes done to the master files and drop the temporary tables if any used in the Acceptance Test.

6 6 Process Example Following steps are followed (slight variations may exist among TDD practitioners): 1. Understand the requirements of the story, work item, or feature. 2. RED: Create a test and make it fail. Need to wirte the test case (appropriate input datasets and the expected result sets) assuming the code already existed for the new requirement. Now run the test, it should FAIL. This is a calibration measure to ensure that the test is calling the correct code and that the code is not working by accident. This is a meaningful failure, and expects it to fail. 3. GREEN: Make the test pass by any means necessary. Now write the code to make the test case PASS. If new functionality is still needed, then another test is needed. Make this one test pass and continue. 4. REFACTOR: Change the code to remove duplication in your project and to improve the design while ensuring that all tests still pass. a. Remove duplication caused by the addition of the new functionality. b. Make design changes to improve the overall solution. c. After each refactoring, rerun all the tests to ensure that they all still pass. 5. Repeat the cycle. Each cycle should be very short, and a typical hour should contain many Red/Green/Refactor cycles. This process is of course a bit time consuming but once the test case is prepared the result it yields ensures 100% accuracy. From DART prospective If the actual result set of running the test case in DART after coding matches with the expected result set then it looks as shown in figure 3. Fig 3: Passed AT. However if the actual result set of running the test case in DART after coding do not matches with the expected result set then it looks as shown in figure 4.

7 7 Fig 4: Failed AT The beauty of this tool is it helps the developer to very easily identify which particular data value is mismatching. The mismatched values are marked as RED as shown in the fig4. The developers can directly hit the objects (functions/methods/stored procedures etc) that are responsible for correcting the mismatched values. Once the test case passes for the new functionality, the whole set of test cases that already exist need to run in order to check if the new change somehow breaks the existing test cases (i.e., existing functionality). In our project, these test cases run into hundreds (approx 600 acceptance tests already exist). To manually run all these after every new test passes is out of question as we have to keep a dedicated resource to run one by one all the existing ATs along with the new AT. DART tool enable us to run the full suite of the Acceptance Tests at one go. To run all the test cases need approximately 8 hours. The result that the tool gives after the suite completes is shown in figure 5. Fig 5: Sample of the result set after running full suite of ATs. From the above figure once can be clearly identify which existing Acceptance Tests are broken after running the full suite. One can start running the full suite of Acceptance Tests at night before leaving office and by morning next day the running of Acceptance Tests gets completed.

8 8 Results achieved Total number of successful conversion (Go-Live and Controlled) has exceeded 400 for Soarian Financials. Each event heavily depends on the DART Tool and its automated Acceptance Tests for successful QA. TDD based coding ensures 100 % accuracy in converting data every time. Coding re-work effort pertaining to SQL code is less than 0.25%. Impact of not using DART Tool (TDD) in our project Full testing of existing code along with the new functionality would never been possible. Bugs injected due to new code could be detected. To manually test the Acceptance Tests a dedicated resource should be engaged to run all the acceptance tests (600+ ATs) one by one after every new AT and code added. Simply wastage of that resource s skill. Developers get a clear idea of the story or the work they intend to do by looking at the Plan Detail and the expected result grid. Without DART developers have to greatly depend on the Analyst for their inputs. CASE STUDY My primary objective is to compare and evaluate the impacts of Test-Driven Development with Traditional Development taking into account factors related to Software quality assurance, productivity factors etc through an incremental process. Experimental Data for 1 month Target was to write 10 Acceptance Tests with full suite testing after every new test and code added Number of test cases/coded and tested written Number of faults detected during acceptance testing Time required to complete running full suite of ATs Person hours spend for testing the full suite of ATs after complete one new test case. Total effort spend for each new AT(writing test case, coding and full testing) TTD (using DART) Traditional Approach (not using DART) hrs 16hrs 0 hr (running full suite is automated) 16 hrs 7 to 8 hrs 53 hrs The results clearly reveal the fact that the total number of faults in acceptance

9 9 testing was lower in TDD when compared to the traditional approach. The overall time taken by TDD was also 46 hours less than the traditional approach. The decrease in the number of faults during the testing phases in the TTD may be attributed to a number of factors such as the immediate feedback provided by the test cases and the high number of tests performed by the programmers in that group. As Edsgar Dijkstra, a Dutch computer scientist said The programmer should let the program proof and program grow hand in hand which means for example when a loop is incorporated in the code, a corresponding loop invariant test case is generated and the code is checked as the design is refined or refactored. Best practices learnt applicability to other projects Any project that involves data transformation (using relational databases) in a large scale can make use of the DART Tool. Projects that have in-bound and out-bound modules in the OLTP environment can configure the DART Tool for regression testing. Benefits of Test-Driven Development The suite of acceptance tests provides constant feedback that each component is still working. The acceptance tests act as documentation that cannot go out-of-date, unlike separate documentation, which can and frequently does. When the test passes and the production code is refactored to remove duplication, it is clear that the code is finished, and the developer can move on to a new test. Test-driven development forces critical analysis and design because the developer cannot create the production code without truly understanding what the desired result should be and how to test it. The software tends to be better designed, that is, loosely coupled and easily maintainable, because the developer is free to make design decisions and refactor at any time with confidence that the software is still working. This confidence is gained by running the tests. The need for a design pattern may emerge, and the code can be changed at that time. The test suite acts as a regression safety net on bugs: If a bug is found, the developer should create a test to reveal the bug and then modify the production code so that the bug goes away and all other tests still pass. On each successive test run, all previous bug fixes are verified. Reduced debugging time! CONCLUSION Test-driven development (TDD) is a development technique where one first writes a test case that fails before writing a new functional code or updating an existing code. TDD is being quickly adopted by agile software developers for development of application source code as well as database development.

10 10 TDD does not replace traditional testing; instead it defines a proven way to ensure effective unit and regression testing. A side effect of TDD is that the resulting tests are working examples for invoking the code, thereby providing a working specification for the code. Our team s experience is that TDD works incredibly well in practice and it is something that all software developers should consider adopting to develop software quality and productivity and lower the costs in maintaining it at a later time. Reference [1] Chaplin, D., "Test First Programming," TechZone, [2] Beck, K., Test Driven Development: By Example: Addison Wesley, [3] Boehm, B. W., Software Engineering Economics. Englewood Cliffs, NJ: Prentice-Hall, Inc., Author s biography Payal Sen is consultant at Siemens Technology And Services Pvt Ltd (STS), Kolkata. She received her B.Tech degree in Electronics and Communication in After passing out she joined Wipro InfoTech and then around May 2007 she joined STS, Kolkata. For 5 years she worked with Conversion Project as developer and for last 1 year she is working as Analyst for Patient Access. She represented Kolkata in Bird-Of-Feather (BOF) workshop on the topic of Test Driven Development (TDD) held at Bangalore. She was the second runner of an internal paper submission competition organized by STS and the topic of her paper was Effective Development and Testing using TDD.

11 11