Test Driven Development (TDD) is a software development practice in which unit test cases are incrementally written prior to code implementation. In our research, we ran a set of structured experiments with 24 professional pair programmers. One group developed code using TDD while the other a waterfall-like approach. Both groups developed a small Java program. We found that the TDD developers produced higher quality code, which passed 18 % more functional black box test cases. However, TDD developer pairs took 16 % more time for development. A moderate correlation between time spent and the resulting quality was established upon analysis. It is conjectured that the resulting high quality of code written using the TDD practice may be due to the granularity of TDD, which may encourage more frequent and tighter verification and validation. Lastly, the programmers which followed a waterfall-like process often did not write the required automated test cases after completing their code, which might be indicative of the tendency among practitioners toward inadequate testing. This 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.

Unit testing is one of the core practices in the Extreme Programming lightweight software development method, and it is usually carried out with the help of software frameworks that ease the construction of test cases as an integral part of programming tasks. This work describes our first results in studying the integration of automated unit testing practices in conventional ‘introduction to programming ’ laboratories. Since the work used a classical procedural language in the course’s assignments, we had to design a specific testing framework called tpUnit. The results of the experiment points out that a straightforward approach for the integration of unit testing in first-semester courses do not result in the expected outcomes in terms of student’s engagement in the practice. 1.

“Nightly/daily building and smoke testing ” have become widespread since they often reveal bugs early in the software development process. During these builds, software is compiled, linked, and (re)tested with the goal of validating its basic functionality. Although successful for conventional software, smoke tests are difficult to develop and automatically rerun for software that has a graphical user interface (GUI). In this paper, we describe a framework called DART (Daily Automated Regression Tester) that addresses the needs of frequent and automated re-testing of GUI software. The key to our success is automation: DART automates everything from structural GUI analysis, test case generation, test oracle creation, to code instrumentation, test execution, coverage evaluation, regeneration of test cases, and their re-execution. Together with the operating system’s task scheduler, DART can execute frequently with little input from the developer/tester to retest the GUI software. We provide results of experiments showing the time taken and memory required for GUI analysis, test case and test oracle generation, and test execution. We also empirically compare the relative costs of employing different levels of detail in the GUI test cases. 1.

A longitudinal case study evaluating the effects of adopting the Extreme Programming (XP) methodology was performed at Sabre Airline Solutions™. The Sabre team was a characteristically agile team in that they had no need to scale or re-scope XP for their project parameters and organizational environment. The case study compares two releases of the same product. One release was completed just prior to the team’s adoption of the XP methodology, and the other was completed after approximately two years of XP use. Comparisons of the new release project results to the old release project results show a 50 % increase in productivity, a 65 % improvement in pre-release quality, and a 35 % improvement in post-release quality. These findings suggest that, over time, adopting the XP process can result in increased productivity and quality. 1.

Much of the elegance and power of Smalltalk comes from its programming environment and tools, but despite the passage of more than 20 years, the Smalltalk browser is much the same today as when it was first introduced. We have extended this browser with features that dramatically improve its support for incremental programming by employing real-time analysis of the code being modified. We illustrate these improvements by example, and summarize the algorithms used to implement them efficiently.

Abstract not found

This paper presents a single case study reporting the experiences of introducing extreme programming (XP) in a small development project at Online Telemarketing in Lund, Sweden. The project was a success despite the fact that the customer had a poor idea of the system required at the start of the development. This success is partly due to the introduction of practically all of the XP practices. The practices that worked best were the planning game, collective ownership and customer on site. The practices that were found hard to introduce and not so successful were small releases and testing.

Industrial practice in software engineering has developed in recent years from rigid heavyweight document-based development techniques, such as the Rational Unified Process, to incorporate more agile, iterative, communication-centric approaches such as Extreme Programming. This shift has created a need for a similar shift in software engineering education. We report our experience of incorporating an Extreme Programming option into an existing document-centric software project course. While students taking the option were generally positive about Extreme Programming, the projects' external clients had a more mixed experience.

Students in programming courses generally write "toy" programs, even when the size of the assigned projects is large. Programming assignments are written, superficially tested, graded, and then discarded. This approach to programming pedagogy leaves students unprepared for production programming in the workplace because the gap between writing toy programs and developing reliable software products is enormous.

In this paper, we present a case study comparing the productivity resulting from applying some agile practices (from Extreme Programming) with a more conventional OO software development approach. We show four productivity metrics gathered from a small software company before and after adopting agile practices. The data shows strong productivity gains.