Towards Software Configuration Management for Test-Driven Development

Towards Software Configuration Management for Test-Driven Development

Tammo Freese

OFFIS, Escherweg 2, 26121 Oldenburg, Germany [email protected]

Abstract. Test-Driven Development is a technique where each change to the observable behavior of a program is motivated by a failing test.

High design quality is maintained by continuous small design improve- ments called refactorings. While some integrated development environ- ments support automated refactoring, they do not handle problems that occur if refactorings are used in development teams or on published inter- faces. This paper outlines the idea of a specialized software configuration management tool which integrates into a development environment to record the steps of Test-Driven Development as operations. These oper- ations are useful for summarizing local changes, merging parallel changes and for migrating code that uses published interfaces.

1 Introduction

Test-Driven Development (TDD) [3] is the core development strategy of Extreme Programming [2]. The main ideas of TDD are to test a program before writing it, and to continuously maintain a simple design.

Each change of the observable program behavior has to be motivated by a failing test. Seeing the test fail is important, as it verifies that the code does not fulfil the test’s expectations. After writing just enough code to meet the new expectations, all the tests have to pass to verify that the new expectation as well as all the old ones are fulfilled. The tests are written by developers in the development language itself using a testing framework like JUnit [10]. The GUI front ends of these frameworks provide visual feedback. A green bar means that all tests passed, while a red one means that at least one test failed. Each development step may be understood as a state transition green–red–green.

Every development step introduces new behavior. The current design is often not fitted to incorporate the new behavior, so it may grow more complex with every change. To keep the design straightforward and easy to understand, it is required to improve it without changing the observable behavior of the code.

This is known as refactoring [7]. In TDD, refactoring is only allowed if all exist-

ing tests pass. Since refactorings do not change the observable behavior, all tests

still have to pass afterwards. Refactoring steps thus may be understood as state

transitions green–green. Refactoring steps are typically small. Bigger refactorings

are achieved by many small steps. Examples for refactorings in Java are renam-

ing classes, interfaces or methods as well as extracting and inlining methods.

As performing refactorings manually is slow and error-prone, tool support is es- sential. Some integrated development environments (IDEs) support automated refactoring and thus speed up TDD. However, there are still some shortcom- ings in using local version histories, merging changes and applying changes to published interfaces.

1.1 Local Version History

TDD is a feedback-driven development style with many small steps. From time to time the development may take a wrong path, so that backtracking is necessary.

Common examples are a new test requiring too much code to be written so that the developer does not get back to a green state quickly, or an experimental refactoring route which led to an overly complex or otherwise inappropriate design.

Many IDEs provide undo/redo features, some even provide local histories that allow backtracking to every saved version. However, the huge number of steps in TDD clutters local histories, making it difficult to identify interesting targets for backtracking. An additional problem is that local changes and versions often do not carry additional information, like whether they are refactorings or whether the tests passed. Undo/redo is usually file-related and not project- related, and too fine-grained for backtracking. Common implementations even lose information, since undone development routes cannot be reached again after changes.

1.2 Merging Changes

Commercial software configuration management (SCM) tools usually rely on textual merging [12]. Refactorings often lead to problems when using textual merging. Suppose we have a method x(). While developer A renames the method to y(), developer B implements a new method using the old signature x(). Text- oriented SCM tools will show no merge conflicts, but the resulting code will not compile. Even worse, if both developers rename the same method to different names, textual merging leads to conflicts at every invocation of the method.

Another problem is method inlining. If developer A inlines method x() while developer B invokes it in a new code fragment, no merge conflicts will be shown, although the resulting code will not compile.

1.3 Changing Published Interfaces

Many software development projects work on libraries or frameworks. Changing

published interfaces breaks client code and is therefore discouraged. Typical

recommendations are to publish as little as possible as late as possible or to make

changes additions [8, 5]. While following these rules is generally useful, it makes

TDD more difficult, since refactorings cannot be applied easily to published

interfaces.

2 Software Configuration Management for Test-Driven Development

The main reason for the problems described in section 1 is the missing support for Test-Driven Development in current SCM systems, as they are not aware of the development steps. Our goal is therefore to build a specialized SCM for Test-Driven Development.

2.1 Local Change History

As the SCM should be based on the steps of TDD, these steps have to be recorded. By integration into an IDE, events like saving files, refactorings, compi- lation success/failure and test success/failure may be gathered. With additional information from the source code, we get a sequence of changes, each of them either a delta for some source files or an automated refactoring. Each change may carry additional information on compilation success (compilable change) or failure (non-compilable change) and test success (green change) or failure (red change). With these changes, a simple mechanism for backtracking may be implemented. Backtracking itself is recorded as a kind of change as well.

The stream of changes contains the complete development path, but it does not provide an overview. To focus on important information, the changes are structured into a tree by organizing changes under new parent nodes. Each parent node is regarded as a change and inherits the additional information from its last child. Parent nodes are introduced for various change sequences:

– backtracking changes with all preceding changes they have undone

– changes where compilation was triggered with all preceding changes that were not compiled

– compilable changes with all preceding non-compilable changes

– changes where tests were invoked with all preceding changes where the tests were not invoked

– a maximal sequence of red changes followed by a green change, i.e. a TDD development step

– a maximal sequence of green changes after a green change, i.e. a sequence of TDD refactoring steps

Figure 1 shows a small example where 11 changes are structured in a tree. In the collapsed form, the tree only shows 3 elements.

2.2 Merging Changes

The local change sequence provides valuable information for merging parallel

changes. Our goal is to combine operation-based merging [11] with syntactic

software merging [4]. Operation-based merging uses the operations that were

performed during development. Syntactic software merging takes the program-

ming language syntax into account.

before aggregation after aggregation

number type compile test number type compile test

37–38 non-compilable change F

38 change F 38 change F

37 change 37 change

35–36 refactoring step S S

36 refactoring S S 36 refactoring S S

35 refactoring S 35 refactoring S

28–34 development step S S

33–34 green change S S

34 change S S 34 change S S

33 change F 33 change F

28–32 red change S F

30–32 compilable change S F

32 change S F 32 change S F

31 change 31 change

30 change 30 change

28–29 non-compilable change F

29 change F 29 change F

28 change 28 change

S: success, F: failure Fig. 1. Aggregating changes

For merging parallel changes, we would like to use operation sequences where the code compiles after each change. Thus it is required that the local change sequence starts and ends with compilable code. The operation sequence is created by pruning all the development paths that were undone by backtracking, and combining each compilable change with all its preceding non-compilable changes.

Each operation, then, is either a refactoring or a change to one or more source files. We assume that we have an initial state X of the source code and two operation sequences (transformations in [11]) T

= T

T

. . . T

and T

= T

T

. . . T

. The typical situation is that a developer (B) would like to release his changes T

to X into the repository. While he worked on his changes, another developer (A) has released his changes T

. The result of the re- lease should then be T

T

X = T

T

. . . T

T

T

. . . T

X. Since the operations T

were applied to X and not to T

X, conflicts may occur. The ap- proach followed here is to check each operations of T

for conflicts with operations of T

. Conflicts are resolved by modifying the operations of T

(automatically or manually). The rationale behind this is that T

is never changed, since it is already stored in the repository.

In merging, the basic assumption for operation-based merging is used: If the result of applying two transformations stays the same after changing their order, the result is a good candidate for merging [11]. For merging two non-refactoring operations, syntactic software merging [4] should be used to minimize conflicts.

If a change cannot be applied after a refactoring, it is often sufficient to apply the

refactoring on the change itself. The same strategy works for many conflicting

refactorings. If this strategy does not work, in most cases the conflict is due to a name clash. An example would be a change operation which adds method x() and a refactoring renaming method y() to x(). These cases may be resolved automatically by either modifying the change operation or the refactoring to use another target name. Remaining conflicts should be solved interactively.

2.3 Changing Published Interfaces

If a library or framework is developed, refactorings on published interfaces have to be applied to dependent code, too. Since the change operations themselves are stored in the SCM, a refactoring script may be created for the operation sequence since the last published version of the library. A migration tool may apply these refactorings on dependent code by using the refactoring capabilities of existing tools. Such a tool is expected to reduce migration costs in these cases drastically, so that the development team may establish more liberate change policies on published interfaces.

3 Related Work

The SCM tool outlined here combines various ideas, among them using the change history in the development process, operation-based and syntactic soft- ware merging as well as applying refactorings to code that uses published inter- faces. This section summarizes these ideas and relates them to this paper.

3.1 Version Sensitive Editing

In [1], David L. Atkins describes the idea of enhancing the development pro- cess by making the change history easily available to the programmer. The tool described there is capable of showing the history for each line of code, thus sim- plifying the identification of errors introduced earlier. The local change history described in section 2.1 is guided by the same idea, but takes another approach.

In TDD, different ideas for a code change are often just tried one after another, so it is important to be able to roll back the whole project to an earlier version.

So instead of showing the history of a line of code, the change history here shows the history of the whole project.

3.2 Local Change Histories

Some IDEs ([6, 9]) include local change histories which allow rolling back either

single methods or files or the whole project to older versions. The local change

history proposed here only allows to roll back the whole project. Its advantages

are that it simplifies finding interesting targets for backtracking by structuring

the development steps, and its awareness for refactoring operations which may

later be used in merging.

3.3 Operation-Based Merging

Most SCM tools use state-based merging, as they only have initial and final versions available.

Operation-based merging [11] uses the operations that were performed during development. As refactorings are typical operations in TDD, section 2.2 proposes to use them as operations in merging. All other changes are combined to change operations.

In [11], the operation sequences leading to different versions may both be changed to create the merge result. The approach described here requires that the sequence already in the repository is not changed: All changes have to be applied to the sequence which is not in the repository. As a result, the repository contains a stream of operations from version to version, which may be used for migration of dependent code.

3.4 Syntactic Software Merging

In [4], Jim Buffenbarger provides an overview on methods of software merging, including the idea of syntactic software merging that uses the programming lan- guage for merging. Since the source code is compilable before and after each change operation in section 2.2, two non-refactoring operations are good candi- dates for syntactic merging.

3.5 Refactoring Tags

The strategies for changing published interfaces mentioned in section 1.3 are inappropriate for Extreme Programming, since they focus on avoiding change.

In [13], Stefan Roock and Andreas Havenstein describe the concept of special tags for framework development. The tags describe refactorings applied to the framework. They are used by a migration tool to help application developers in migrating their source code to a new version of the framework.

In comparison to the approach described here, the advantage of refactoring tags is their independence of the development environment: They may be used in every IDE or editor. However, the refactoring information is not gathered automatically, but has to be added manually.

4 Current Status and Future Work

The SCM outlined in this paper is currently under development for the Java programming language. It is integrated into the open source IDE Eclipse [6]

which provides a huge number of plug-in points which greatly simplify tool inte-

gration. At the time of writing (February 2003), the local change history works,

and plug-in points for providing local change types as well as building the tree

structure for the change sequence are finished. Since Eclipse does not yet pro-

vide information on invoked refactorings, we added a related plug-in point, and

currently work on creating the operation sequence from the local development

steps.

References

1. Atkins, D.L.: Version Sensitive Editing: Change History as a Programming Tool.

In: Magnusson, B.: Software Configuration Management: ECOOP’98 SCM-8 Sym- posium. Springer (1998)

2. Beck, K.: Extreme Programming Explained: Embrace Change. Addison-Wesley (1999)

3. Beck, K.: Test-Driven Development: By Example. Addison-Wesley (2003)

4. Buffenbarger, J.: Syntactic Software Merging. In: Estublier, J. (ed.): Software Con- figuration Management: Selected Papers SCM-4 and SCM-5. Springer (1995) 5. des Rivi` eres, J.: Evolving Java-based APIs. http://www.eclipse.org/eclipse/

development/java-api-evolution.html (2002) 6. Eclipse home page. http://www.eclipse.org

7. Fowler, M.: Refactoring: Improving the Design of Existing Code. Addison-Wesley (1999)

8. Fowler, M.: Public versus Published Interfaces. In: IEEE Software (March/April 2002)

9. IntelliJ IDEA home page. http://www.intellij.com 10. JUnit home page. http://www.junit.org

11. Lippe, E., van Oosterom, N.: Operation-based Merging. Lecture Notes in Computer Science, Vol. 1000. In: Proceedings of ACM SIGSOFT’92: Fifth Symposium on Software Development Environments (SDE5) (1992)

12. Mens, T.: A State-of-the-Art Survey on Software Merging. In: IEEE Transactions on Software Engineering, vol. 28, no. 5 (2002)

13. Roock, S., Havenstein, A.: Refactoring Tags for automated refactoring of frame-

work dependent applications. XP2002 Conference (2002)