Agile & DevOps - Test Driven Development

Vimala Magdaline, Senior Quality EngineerJeba Gunasekaran ,Expert Quality Engineer

Allscripts LLP

Abstract

A well-written codebase saves time and money, and can withstand the test of time and doing things efficiently. If there’s a way to write quality code and save time and money, that’s the kind of service we can provide to our clients. This Paper talks about Test Driven Development which is originally derived from XP practice and has become a critical pillar supporting Agile methodology. The Goal of TDD is to write Clean code that works.

1. Introduction

Test-Driven Development (TDD) is a technique that involves writing test cases first and then implementing the code necessary in order to pass the tests. The goal is to achieve immediate input and thereby construct a program. This technique is heavily emphasized in Agile or Extreme Programming [1, 2, 3]. This process of designing test cases prior to the implementation is termed as “Test-First “approach. We consider unit-testing only (by the programmers) and have nothing to do with integration or acceptance testing. But we do take into account the number of faults found while SQA performs formal unit testing, integrating and performing acceptance testing in order to measure the quality of the software produced. The first step in this approach is to quickly add a test, basically just enough code to fail. Then we run our tests, generally all of them but in order to finish the process quickly, may be only subsets of tests are run to make sure that the new test does fail. We then update the code in order to pass the new tests. Now, we again run our tests. If they fail, we again have to update and retest, else we add the next functionality. There are no particular rules to form the test-cases but more tests are added throughout the implementation. Though, refactoring should be performed in agile programming that is programmers alternate between adding new tests and functionalities to improve its consistency. It is done to improve the readability of code or change of design or removal of unwanted code.

There are various advantages in employing TDD.Programmers tend to know immediately whether the new feature has been added in accordance with the specifications. The process is performed in steps comprising of small parts and hence easier to manage. Low number of faults are tend to be found during acceptance testing and maintenance can be viewed as another increment or addition of feature which would make it easier. There is no particular design phase and software is built through the process of refactoring. In short, TDD improves programmer productivity and software quality.

2. Methodology

The following figures demonstrate the approaches employed by both the projects. The methodology for TDD is depicted by figure 1 and the conventional method by figure 2. In TDD, a test is added and tested with the code produced. Code is reworked until all the tests are passed. Additional features are added one by one in an incremental process. Additional tests are added to the test bed as and when needed. In the traditional way all the implementation is completed and then test cases are designed. The code is run through all the tests and is reworked until desired functionality is achieved.

3 . How QA can support TDD?

The first step a developer must take when following TDD is to write the test case, knowing the user requirement that needs to be met. When complete, the test case is executed, without any code, therefore it is bound to fail. Next, the developer will write just enough code to pass the test case. No extra functionality will be coded until this test case is passed and a new testcase is written to test the next level of functionality. To pass a test the observed output must match the expected output exactly.  The development of a project continues in this fashion, write a test case, execute the test case, write the code to pass the test, execute the test case. If it passes then move on and write the next test case, otherwise modify the code to try to pass the test again.

As development of the software progresses and the code size increases, refactoring is allowed however the code must still pass ALL of the original test cases, otherwise the refactoring is faulty.

The tester can help in this process through mentoring the developer in order to facilitate knowledge transfer around test analysis and design. This will probably require the tester to have some technical expertise as whilst they will not be writing the code they will need to be able to understand it to a certain depth. The tester can help facilitate the negative testing which is an area that developers tend not to focus on as they primarily are testing to make sure that their code does what is supposed to do and not that it doesn’t do what it shouldn’t do.

There are also other derivatives of TDD and these are:

ATDD (Acceptance Test Driven Development) FDD (Feature Driven Development)

4. The Value of TDD and CI

Test-driven Development and Continuous Integration are complementary practices. Code produced test-first tends to be well designed and relatively easy to integrate with other code. Incrementally adding small pieces of a system to a central source code control system ensures the whole system complies without extensive integration work. Running tests allows developers to find integration problems early as new code is added to the system. An automated build system complemented by regression test suites ensures a system grows responsibly in features and size and exists in a near ready- to release fashion at all times.

The thought of continuously integrating is to find issues speedily, consequently giving every developer feedback on their work, and then there must be somehow to assess that work instantly. Test- driven development fills that gap.

With TDD, you construct the test then after that develops functionality until the code passes the test. As every revamped expansion to the code is made, its test could be added to the suite of tests that are run when you build the integrated work. This guarantees that revamped additions don’t break the functioning work that preceded them, and planners whose code does as a matter of fact “break the build” could notified quickly. A typical combination of continuous integration and TDD is illustrated in figure below.

5.The Case Study

In a research with 2 groups of projects, one developing software the conventional way of testing it after implementation and the other group through TDD. In both groups, test cases were developed by programmers and regression testing was performed. Only difference is test cases are written prior to implementation and are tested throughout the production in TDD and test cases are written and tested after implementation in the conventional way in Traditional approach. We investigate in this paper through experimental studies the promise of “Test-First” strategy emphasized in agile programming.

Our 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. A simple logic is that more test cases obviously would enhance software quality and hence software quality of TDD should be better than that of the traditional approach of testing. Fault free code ensures less time in maintaining the software which is a very important thing as maintenance accounts to almost 70% of total costs during the life time of software. We thus measure the number of test cases written by both Project teams and determine if quality improved and thus evaluate if TDD is a better approach for testing

software.

6. Conclusions

We noted the significance of test-driven approach emphasized by agile programming order to develop software quality and productivity and lower the costs in maintaining it at a later time. Through our experiment we showed the TTD approach yielded better results with respect to both quality and productivity. This is because of the way test cases were designed as the software was being developed. Focus on smaller subsets of information and a large number of test cases designed along with program development lessened the rework time and promoted quality. Though, our results encourage the employment of TTD approach, one should consider the size of the software project implemented. We can with confidence say that TTD approach may be a good choice in comparison with the traditional approach for small sized software projects. The usefulness of the approach needs to be validated by using it for larger projects involving larger group numbers.

References & Appendix https://dojo.ministryoftesting.com/lessons/what-does-tdd-mean-for-me-the-

tester K. Beck, Test-Driven Development: By Example. Addison Wesley, 2003. https://www.infoq.com/articles/testers-TDD-teams Agile Testing Alliance Reference book

Author BiographyJeba GunasekaranExpert Quality Engineer, Allscripts Jeba.Gunasekaran@Allscripts.com10+ years of experience in Software Testing Certified Scrum Mater

Vimala MagdalineSenior Quality Engineer, Allscripts Vimala.Magdaline@Allscripts.com12+ Years of experience in Software Testing Certified Professional Master Agile Testing

THANK YOU!