Abstract In this paper, we conduct an experimental study over two groups of students comprising of undergraduate students (seniors) who develop software using the conventional way of performing unit testing after development and also by extracting test cases before implementation as in Agile Programming. Both groups developed the same software using an incremental and iterative approach. The results showed that the software had less number of faults when developed using Agile Programming. Also, the quality of software was better and the productivity increased. Keywords: Test driven development, agile programming, case study 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 in 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. There have been a number of studies [4, 5, 6, 7] that have been performed to test the effectiveness of TDD and the results give mixed opinions. We perform an experiment with 2 groups of students, 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. Each group consisted of 9 undergraduate students and time period for the whole study was 3 months. We investigate in this paper through experimental studies the promise of “Test-First” strategy emphasized in agile programming.
[1]
Matthias M. Müller,et al.
Experiment about test-first programming
,
2002,
IEE Proc. Softw..
[2]
Marco Torchiano,et al.
On the effectiveness of the test-first approach to programming
,
2005,
IEEE Transactions on Software Engineering.
[3]
Stephen R. Schach,et al.
Object-oriented and classical software engineering
,
1995
.
[4]
Kent L. Beck,et al.
Extreme programming explained - embrace change
,
1990
.
[5]
Walter F. Tichy,et al.
Case study: extreme programming in a university environment
,
2001,
Proceedings of the 23rd International Conference on Software Engineering. ICSE 2001.
[6]
G. A. Miller.
THE PSYCHOLOGICAL REVIEW THE MAGICAL NUMBER SEVEN, PLUS OR MINUS TWO: SOME LIMITS ON OUR CAPACITY FOR PROCESSING INFORMATION 1
,
1956
.
[7]
Alexandra Poulovassilis,et al.
Classical and Object-Oriented Software Engineering with UML and C++, Stephen R. Schach, McGraw-Hill, 1998 (Book Review)
,
2000,
Softw. Test. Verification Reliab..
[8]
Edsger W. Dijkstra,et al.
The humble programmer
,
1972,
CACM.
[9]
Stephen H. EDWARDS.
Using Test-Driven Development in the Classroom : Providing Students with Automatic , Concrete Feedback on Performance
,
2003
.
[10]
Kent L. Beck,et al.
Test-driven Development - by example
,
2002,
The Addison-Wesley signature series.
[11]
Dave Astels,et al.
Test Driven Development: A Practical Guide
,
2003
.