Using Spring Roo for theTest-Driven Development of Web Applications

Tim A. MajchrzakDepartment of Information Systems

University of MünsterMünster, Germanytima@ercis.de

Andreas SimonIndependent

Münster, Germanyresearch@andreas-simon.info

ABSTRACTSoftware should be developed in a way that achieves high ex-ternal and internal quality. Most programs have to be main-tained or are extended. They should not only adhere to theirrequirements but allow to be efficiently changed. Model-driven software development (MDSD) and test-driven devel-opment (TDD) are techniques that help to satisfy this de-mand. We present a novel approach combining MDSD andTDD while using the Spring Roo Web development frame-work. Besides discussing existing work and the background,we sketch a test-driven Web development process. We thenevaluate its feasibility in an exemplary scenario. Thereby,we contribute to the body of scientific knowledge on Webdevelopment frameworks in the field of MDSD and TDD.

Categories and Subject DescriptorsD.2.2 [SOFTWARE ENGINEERING]: Design Tools andTechniques—Software libraries; K.6.3 [MANAGEMENTOF COMPUTING AND INFORMATION SYSTEMS]:Software Management—Software development

General TermsDesign, Experimentation, Performance

Keywordstest-driven Development, TDD, Web application, Web de-velopment, Spring, Spring Roo

1. INTRODUCTIONOnly rarely, software is programmed and used without

changes until it is put out of service. Since defects arefound after it is rolled out, requirements change, compat-ibility issues arise, new platforms have to be supported, andfor many other reasons, most programs require maintenance.Software undisputedly ages [43]. Typically, total costs formaintenance greatly exceed development costs [37]. Even if

Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.SAC’12 March 25-29, 2012, Riva del Garda, Italy.Copyright 2012 ACM 978-1-4503-0857-1/12/03 ...$10.00.

maintenance is not caused by a lack of functional quality—i.e. there has been sufficient testing—costs can be reducedby developing software in a style that aids maintenance.

Two programs with the same functionality and qualityas seen from a users’ perspective (external quality) mightbe different in internal quality. Thus, the effort to alterthem differs. Developing Software with future changes inmind prepares it for maintenance and extension. However,what fosters internal quality is not obvious. Typical designdecisions are modularity vs. simplicity and reusability vs.specialization; their impact is subject to discussion [7].

Model-driven software development (MDSD) has been pro-posed as a method to increase internal quality while enablingefficient development. The idea is to create programs froman abstract representation (model). Model-driven develop-ment is becoming increasingly popular for Web applications.Spring Roo is an example for a Java-based framework thatcan be used for MDSD of programs that are deployed to Webservers or application servers. Another technique that seeksto increase external and internal quality of software is test-driven development (TDD). It refrains from an approach inthat coding is followed by testing. Code is implemented af-ter the corresponding test case has been written. Therefore,TDD is also called test first development [8]. Programmingis finished if the test case can be executed successfully [16].

Our research question is: is it possible to develop Web ap-plications in a model-driven way while working test-driven?Besides this question, we wanted to have a closer look atSpring Roo, which is a novel framework for MDSD and hasnot been scientifically assessed, yet (see Section 2).

Our work makes several contributions. Firstly, it showshow Spring Roo can be used for TDD. Secondly, findingsare generalized to make our work both relevant and rigorous.Thirdly, we comprehensively describe particularities of com-bining MDSD and TDD for Web development. Fourthly, weintegrate our work into the prevalent research and explaindifferent threads of work currently followed.

This paper is structured as follows. In Section 2, we dis-cuss related work. Our work’s background is compiled inSection 3. Section 4 explains our proposal for test-drivendevelopment using Spring Roo. A exemplary scenario andan evaluation of our work is given in Section 5. Finally, wedraw a conclusion and highlight future work in Section 6.

2. RELATED WORKThere is a myriad of papers on MDSD—which also uses to

be called model-driven engineering (MDE) [53]—and TDD.In fact, both approaches are well-studied and even textbooks

664

have been published [54, 8]. Hence, we will focus our liter-ature review on work that integrates MDSD and TDD, andon work that deals with model-driven or test-driven Webdevelopment frameworks. Finally, general papers on SpringRoo can be compared with our work.

The approaches that integrate MDSD and TDD, which weknow of, can hardly be compared to our work. Zhang forexample uses a test-driven modeling approach in MDSD [57].While this is an integration of the two concepts, it is differ-ent in aim to our work. Some other approaches are far morespecialized such as work on model-transformations based ona test-driven method [28]. There also are approaches thatcombine TDD with model-based testing such as [56]. How-ever, we deem model-based testing and MDSD two indepen-dent approaches even though both rely on models and thesame models can be used for testing and coding purposes.

In the context of Web development, MDSD [29, 52, 20]and TDD [46, 48, 33] are actively discussed. The work pub-lished in recent years is the foundation for our work sinceit illustrates the feasibility of using MDSD and TDD whendeveloping Web applications. However, neither of these ap-proaches directly fosters our work.

Work on Spring Roo still is relatively limited. This par-ticularly applies to a scientific examination of it. While itis dealt with in two textbooks on Spring from 2010 [36, 23],Roo is not included in older titles. This is not surprisingsince its first version was released in late 2009 [4]. A prac-titioner’s book has been published in August 2011 [34] withadditional titles announced for winter 2011 [51, 47]. Whilebeing mentioned in some scientific papers, we only identifiedone that uses Roo as a base for own work. Castrejon etal. present a framework for model-driven Web developmentthat extends Spring Roo [14]. We expect more papers thatdeal with Roo to appear while our work is under review.

Finally, we identified one approach that has a connectionto our work due to dealing with MDSD, TDD, and Webapplications. Robles Luna et al. “combine the agile, iter-ative and incremental style of test-driven development withthe more formal, transformation-based model-driven Webengineering” [49]. Thereby, their work is process-orientedwhereas we focus on a framework directly. Thus, their ap-proach and ours are complementary. In a newer paper, theirwork is extended to include usability requirements [50].

Additionally, the use of scripting languages such as Groovy[18] and JRuby [41] is notable. Since scripting languageshave been ported to the JVM, they become wider recog-nized [11] in Java-centered companies. Scripting languagesallow programming with less syntactical constraints. Whilethey are not directly related by general idea, learning fromresearch on scripting languages might improve our work.

3. BACKGROUNDTo motivate TDD of Web applications, we describe the

background of technology and methodology.

3.1 Particularities of Web ApplicationsWeb applications deliver functionality through browsers

via the World Wide Web. They are constrained by the archi-tecture of the Web and technologies such as HTTP, HTML,and JavaScript that limits the freedom for implementation.

Although the possibilities of Web developers are limited,Web applications apparently have become the most impor-tant technological platform for new applications because of

Testing Coding

Designing

Figure 1: TDD process model

lower maintenance cost compared to locally installed appli-cation (typically rich clients). Moreover, Web applicationsare accessible all over the world. These possibilities foundtheir interim peak in software as as service (SaaS) offers [2];applications are delivered exclusively via the Web [12].

Users’ expectations in terms of business functionality, us-ability, and user experience have raised enormously [55].This makes Web applications very complex. They are hardto maintain and evolve. Some of the requirements are coun-tered by the invention of the Ajax (asynchronous JavaScriptand XML) technology that enables asynchronous communi-cation between the browser and the Web server. The HTMLdocument can be updated by means of JavaScript.

The magnitude of available browsers complicates the sit-uation even further. Web applications are written oncebut have to respect the peculiarity of each of the browsers.The browsers differ—partly dramatically—in the implemen-tation of the Web standards such as HTML and the layout.This led to the so called browser wars [39]. In addition, com-puters use different screen sizes and the upcoming, Internet-enabled mobile devices make the situation even more compli-cated. Developers have to ensure in a effective and efficientway that applications are executed correctly by combina-tions of different browsers, screen resolutions, and devices.That makes regression testing a challenging endeavor.

3.2 Test-Driven DevelopmentKent Beck proposed Test-Driven Development (TDD)

in the course of Extreme Programming [6, 7]. Today, it isa central practice in agile software development [40]. TDDis a micro-process for the implementation of new function-ality. It comprises three phases (see Figure 1). The firstphase is testing : Write a failing (unit) test. It might be im-possible to compile it because invoked methods are not yetimplemented. The failing test motivates the incremental im-plementation of missing functionality. This is similar to anexecutable specification [8]. Coding follows testing. Add justenough production code to pass the test (and all formerlyexisting tests [8]). This might provoke bad design but that isnot in focus in this phase [37]. Finally, designing (refactor-ing) is conducted. Eliminate all the duplication created inthe former step until the new code is cleaned up. It is an ex-plicit design phase [8]. Refactorings are small changes to theinternal structure of a program without changing their exter-nal behavior [42]. Through refactoring, non-functional at-tributes like simplicity, flexibility, understandability or per-formance can be improved systematically.

After one cycle through the three phases, a new cycle isstarted with the next test in order to add more functional-ity. By cycling over and over again the functionality of theproduct is built up. The growing number of automated testsavoids regressions. Through refactoring the internal qualityof the software is maintained or even improved.

The foremost goal of TDD is high product quality. Newcode should never influence existing functionality. Every

665

formerly written code has to keep working correctly [30].Automated test execution improves the quality assessmentsince a machine always executes the same steps in the samesequence; a human tester occasionally errs. In addition, astultifying play-back of a test script is not a very satisfyingwork and leads to a decline of the employee motivation [21].Furthermore, automated programmer tests advance betterdesign. The better the design is, the easier unit testing be-comes. Programmers are motivated to develop highly cohe-sive, loosely coupled components to simplify their work [8].The additional activities increase development time by 15%to 35%. In return, the overall product quality is improved;the error rate can be reduced by 40% to 90% [40]. Theseobservations have been verified experimentally [13].

Development efficiency can be improved through automa-tion [21]. More tests can be executed more often becausetest execution is much cheaper compared to manual testing.Especially regression tests [45] become more economic. Fre-quent execution in test cases advance the trust in the systemstability. By a frequent, almost continuous test execution er-rors are detected very soon after their creation, and fixingthem is relatively cheap. This lowers the cost for removingdefects [8]. Finally, automated tests can serve as a commu-nication medium. Well written tests express the functional-ity intended by the developer. They serve as an automatedspecification for the respective component. Other developerscan get a quick grasp of the intents of the primary developer.Tests save and transport knowledge within the team [13].

Test-driven development is constrained to implementationand design activities carried out by the developers. Thereis no integration of the customer. Through acceptance-test-driven development (ATDD) the principles of TDD are ex-tended to the whole development process [31].

In agile projects, requirements typically are captured asuser stories. They define only the scope of a requirement,not the actual specification. The user story with the high-est priority is picked and specified in the form of one ormore acceptance tests [31]. Acceptance tests are owned bythe customer, written together by customer, developer, andtester, address the what and not the how, expressed in thelanguage of the problem domain, and concise, precise andunambiguous [17]. It is vital to write readable and under-standable acceptance tests. Since customers shall be activelyinvolved in requirements analysis, they must be able to atleast understand the acceptance tests. Acceptance tests arethe central communication medium in ATDD.

Eventually, acceptance tests are automated. All auto-mated acceptance tests form the ”executable product def-inition” [31]. Often acceptance tests are realized as blackbox tests going end to end. The system as a whole is con-figured almost like in production. It is executed throughthe top layer (usually the user interface) and involves eachof the application’s components. In effect, the acceptancetests are likely to harness most of the technical and logi-cal problems. However, executing functionality through theuser interface (UI) is relatively slow, which deteriorates thefeedback speed. Because automation requires a very highlevel of concretion, there is lower risk for misinterpretationand misunderstanding between customer and developer.

Finally, the specified functionality is implemented in or-der to pass the acceptance criteria. Programmers benefitfrom the unambiguous semantics of automated acceptancetests when they implement functionality. Working from the

Active Code Generation

Passive Code Generation

Feedback

SymbolsPhysical artifact Extension component Meta model

instantiation

Feedback

Spring ShellAnnotated class

stubs

Inter-type declarations

OperationsCommands

Meta data

provider

Model meta data

ITD meta data

Model meta data

Annotated class stubs

invokes invokes gener-ates

serial-ization

serial-ization

gener-ates

for-warded toparsing

Figure 2: Manual and automatic code generation

outside in also is one of the goals of behaviour-driven devel-opment (BDD) [15].

3.3 Spring RooSpring Roo (or just Roo) is a round-trip code generator

framework [44] that generates most of the artifacts needed inSpring-based Web applications [32]. It is divided into a coreand several extensions. The core provides a meta model forthe project artifacts and tools for code generation. Basedon formal models, namely the entity classes annotated withmeta data for the code generators, the application is gener-ated. Thus, Spring Roo is one implementation of MDSD.

While the core provides only the basic infrastructure, ad-ditional useful functionality is provided by add-ons. Thereare base add-ons and third-party add-ons. Base add-ons aredelivered together with the Roo distribution. They supportthe generation of model classes, persistence components andWeb application components. They facilitate the quick de-velopment of prototypes based on scaffolding [45]. Third-party add-ons can be installed from any URI with a specialcommand via the Roo shell (see below).

The user is guided by the Roo shell, a custom commandline interface (CLI). By means of Roo shell commands theuser can generate the annotated domain model classes andnecessary XML settings. This is called passive code genera-tion. The alternative is called active code generation. Rooconstantly monitors the class path. When a model class iscreated, changed or deleted, the corresponding meta data isupdated and the depending artifacts (e.g. Inter-Type Dec-larations or XML files) are synchronized. This comprisesaspects, controllers, and views. If representations change,Roo reserializes the artifacts and ensures their consistency.The two ways of code generation [5] can also be called man-ual and automatic. They are visualized in Figure 2.

The architecture of applications that are generated bySpring Roo can be described by two orthogonal axes (Fig-ure 3). Vertically, the application is structured into twotiers [25]. The entity layer comprises data access functional-ity and business logic. The presentation layer is responsiblefor rendering Web pages. Horizontally, each tier is parti-tioned into a annotated class stub and multiple aspects [47].These aspects provide additional functionality for the baseclasses, e.g. JavaBeans accessors or data access functional-ity. Because business logic and data access logic is combinedin the entity classes, they can be said to implement the Ac-tive Record design pattern [25]. Data constraints for domainobjects are enforced by JSR 303 (Bean Validation) annota-tions [10]. An example is given in Listing 1; attribute title

of class Book is required to have at least a length of 1.

666

Presentation layer

Entity layer

To String(Inter-type declaration)

RDBMS

Active Record(Inter-type declaration)

Finder(Inter-type declaration)Class stub

Object-relational mapper(e.g. Hibernate)

Inter-type declarationController(class stub)

View(JSP)

Figure 3: Architecture of a Web application gener-ated using Spring Roo

public c lass Book {@NotNull@Size (min=1)private St r ing t i t l e ;

}

Listing 1: Bean validation example

The presentation layer is implemented by using SpringMVC 3.0, which is an instance of the Web MVC pattern[25]. The controllers follow the REST architecture [22].

4. TDD WITH SPRING ROOIn the following sections, steps towards a test-driven usage

of Roo are explained.

4.1 Process-Oriented AnalysisWe have introduced three techniques: ATDD, TDD and

MDSD. We now analyze the potential for combining them.Both TDD and MDSD are techniques for implementing newfunctionality. The order of the steps taken out to implementcode are almost inverted (Figure 4). In TDD the first step iswriting the test, followed by implementing the desired func-tionality and eventually cleaning up both the test code andthe production code by applying refactorings. In MDSD,the first step is designing an abstract model and genera-tors, which produce the executable production code. Thisstep implies the design of the resulting system because it isincorporated in the generators. Thereafter, the domain ismodeled and the corresponding system is generated. Thelast step might be generating tests for the production codeto build a test harness that protects against unintended ef-fects when changing the production system.

Obviously, these two approaches are mutually exclusivebecause their processes are too different. But to guaranteethe quality of the code generator one can use TDD for theirimplementation. While TDD and MDSD cannot be usedtogether, there is a natural fit of ATDD and MDSD. Bothare used in different development phases. One can record thecustomer’s requirements using automated acceptance tests.Subsequently, these tests drive the implementation of thedesired functionality.

4.2 Integrating TDD and MDSDOur analysis yields potential for integrating ATDD, TDD

and MDSD. Preliminarily, we denote our test- and model-driven development approach with the term TMDD. The

Testing Coding DesigningTEST-DRIVEN

IMPLEMENTATION

MODEL-DRIVEN

IMPLEMENTATIONModelling Generating the

applicationGenerating

tests

Figure 4: TDD and MDSD

outward, incremental cycle is determined by ATDD. Auto-mated acceptance tests capture new requirements for thecurrent iteration. Depending on the complexity of the newfunctionality, you can choose between three methods for im-plementing the new feature (Figure 5).

Less complex features for which a generator already exists(or a generator is worth investing resources to build it) canbe implemented cheaply in a model-driven manner. Thisapproach is very cost-effective and with proven generatorsthe quality of the generated code will be adequately high.

More complex features are seldom worth building a gener-ator. For example, a very complex search functionality hasexactly one implementation. There is no cost advantage ofmodel-driven “mass production”. Rather, it is more efficientto build this component directly. To ensure good internalquality and thereby low maintenance costs, a test-drivenapproach should be chosen. Obviously, unique componentsrequire additional resources but they provide extraordinarybusiness value and competitive advantage.

Finally, there are features in between the two extremecases. The desired functionality is similar to other generatedcomponents but there are subtle differences in the specifica-tion. This is a valid case for combining MDSD and TDD.First of all, the supportive code is generated. This builds astable basis for the new component. Generated tests mightnow come in handy as a harness against unwanted changes.Afterwards, the component is changed through new (unit)tests. During the change process, some of the generated testsmight break. It is up to the developer to decide whether thisfailure is unwanted and the former change must be revertedor if the specification of the unit differs from the generatedcomponent and the failing test can be deleted safely.

4.3 Supportive Tools and TechniquesTest- and model-driven development approach (TMDD)

can be supported with tools and techniques.

4.3.1 A Java Acceptance Test LibraryCurrently, there is a lack of support for writing automated

acceptance tests in a Java-centered Web project. There arewell established libraries for automated execution of userinteractions inside the browser, e.g. Selenium WebDriver[1]. However, they are technologically-oriented: The respec-tive DOM elements are located by CSS or XPath expres-sions, which are hard to read, especially for non-technicalcustomers. Hence, we developed a dedicated library thataids in abstracting from technical details towards a business-centered form of acceptance tests. Our library integrateswith JUnit 4, the de-facto standard in Java test frameworks.

The first benefit is the decoupling of logical UI elementsand technical DOM element IDs. The main entry point toour library is the AbstractAcceptanceTestGroup class. Itprovides several methods, which compute DOM elementsfrom their logical caption. For instance, the method text-

fieldWithLabel(String label) takes the label of a text

667

Low Complexity

Medium Complexity

High Complexity

ImplementFunctionality

Model-driven Implementation

Test-driven Implementation

Assess the Complexityof Requirements

Model-driven Implementation

Test-driven Customization

Choose User Story

Write Acceptance

Test

AutomateAcceptance Test

Figure 5: Integrated process model for TDD withSpring Roo

field as input parameter, looks for the corresponding <la-

bel> tag on the current Web page, extracts the ID of the textfield from the for attribute of the tag and executes an XPathexpression on the DOM to obtain the <input type="text">

element. This makes the tests robust against changes in thecomputation of element IDs. Some Web frameworks—e.g.Java Server Faces (JSF)—compute element IDs automat-ically based on the tree structure of the JSF componentsand the IDs of the parent elements. Both the structure andthe element IDs are subject to frequent change that wouldbreak the acceptance tests without reason—the underlyingfunctionality does not usually change.

The second benefit is improved readability and under-standability of the acceptance tests. This reduces problemsarising from communication problems between customer anddeveloper. It is our goal to enable automated acceptancetests that are as comprehensible as manual tests. When thecustomer is able to read the tests, this might allow skipping“prosaic” acceptance test thus reducing development costs.We foster the readability of acceptance test code by usingintent-revealing names [9, 37]. We deal conciseness for read-ability. The purpose of the method parameters is describedby the method name. To give an example: the methodsbuttonWithCaption("OK") and buttonWithAltText("OK")

reveal the different purpose of the String argument.To work around distracting and irritating keywords of

Java, we use factory methods [27], which hide syntacticalcomplexity from the reader. Instead of e.g. creating a newinstance of AbstractTable directly, one uses the tableWith-Columns(String... columnNames) factory method.

4.3.2 Custom Roo Add-OnTo facilitate the use of our library in Roo projects, we

developed a small add-on. Executing the command accep-

tancetest --story [--storyGroup] on the Roo shell cre-ates a new test class that inherits from our AbstractAccep-tanceTestGroup class. The --storyGroup option eases thelogical grouping of stories. Stories that belong together geta common superclass forming a group of tests.

Issuing the perform acceptancetests command on theRoo shell applies the necessary changes to the Maven buildprocess and directly executes all acceptance tests.

4.3.3 Building a Maintainable Acceptance Test SuiteAlthough our library significantly raises the level of ab-

straction, it is still bound to the solution domain (i.e. Webapplications). By systematic refactoring and smart code de-sign, one can raise the level of abstraction even further andapproach the language of the problem domain. The goal is toformulate acceptance tests in terms of the domain language.We show how to apply well-known techniques on acceptancetest code. These techniques require programming skills, thusaddress developers. Domain experts will not be able to usethem without extensive training.

If you want to evolve a comprehensive specification fromyour acceptance test suite, appropriate arrangement andmeta data become crucial. To improve the searchability andmaintainability, descriptive title for features, user stories,and test cases should be used [3]. A short summary at thebeginning of each feature class helps readers understandingthe purpose. To ease orientation within an acceptance test,you can leverage approaches from BDD, which proposes astandard form for tests: Given—When—Then. Given ex-presses the preconditions that must be fulfilled to be able toexecute the test. There might be multiple given-expressions.They should address domain concepts; technical premisesshould be dealt with in other parts of the automation code.The When part describes the action that changes the systemstate. There is only one such step. Otherwise, the test con-text changes multiple times; that makes it hard to analyze,why a test failed [3]. The Then steps define the postcondi-tions that have to be fulfilled. They tell the tester how tocheck whether the specified feature works correctly.

In order to promote sustainability of the test suite, alltests should be executable in any order at any time. Testinteractions through side effects [38] can be hard to detect.If the test suite becomes unstable, confidence in the tests de-clines and benefits will probably vanish. The simplest meanis setting up the application state from the baseline. In JU-nit, methods annotated with @org.junit.Before can cleanup the database. This way every test asserts that the stateis consistent and deterministic for every execution. Employ-ing @Before instead of @After has another advantage: Afterthe tests ran, the state of the application can be inspected.

To improve readability of test code, it should be refactoredconstantly. With careless development, much data will beduplicated. Think of a base URL of an application. It com-plicates testing the application in a different environment.Besides, a URL as it is usual in a development environment(e.g. http://localhost:8080/) is not easy to understandfor business users. The solution is at hand: extracting aconstant [24] for the base URL such as HOMEPAGE.

Some user actions are the same in multiple tests. To givean example: users have to log in for session-based applica-tions. Instead of repeating the steps for login, these conceptsshould be abstracted by extracting methods [24] capturingthe whole login procedure. With a growing number of ac-ceptance tests, high-level concepts might be scattered amongtest classes. It is useful to create a common super class andpull up general helper methods (Figure 6).

A major hindrance to readability are incidental details [3].This is information that is not relevant to the specified busi-ness rule but still part of the acceptance test. Moving thisinformation to other parts of the code is crucial. Methodscan be extracted and parameters replaced by constants.

668

aGeneralUserStory()anotherGeneralUserStory()login()logout()

HOMEPAGE : String

MyGeneralStories

aSpecificUserStory()anotherSpecificUserStory()login()logout()

HOMEPAGE : String

MySpecificStories

aGeneralUserStory()anotherGeneralUserStory()

MyGeneralStories

aSpecificUserStory()anotherSpecificUserStory()

MySpecificStories

login()logout()

HOMEPAGE : String

AbstractStories

Figure 6: Refactoring Example

5. SCENARIO AND EVALUATIONOur approach is demonstrated using the example of a

simple (book) library management. It has a reasonablecomplexity e.g. complicated validation rules. We create anew Roo project by executing project --topLevelPackage

wwu.library --projectName Book-Library. The initial re-quirement was captured as a user story: As a librarian I wantto enter the meta data of a book to make it borrowable.

This story is illustrated with acceptance tests. Startingwith the happy path we create a new test with the commandacceptancetest --story "Happy-Path" --storyGroup En-

terBookMetadata. Listing 2 shows the result.

public c lass EnterBookMetadataStories {@Test public void happyPath ( ) {

open (HOMEPAGE) ;cl ickClickableAndWaitForNextPage (

l inkWithCaption ( ”New book record ”) ) ;typeText IntoText f i e ld ( ”Design Patterns ” ,

t ex t f i e ldWithLabe l ( ”T i t l e ”) ) ;typeText IntoText f i e ld ( ”Gamma et a l . ” ,

t ex t f i e ldWithLabe l ( ”Author ”) ) ;[ . . . ]

c l ickClickableAndWaitForNextPage (buttonWithCaption ( ”Save ”) ) ;

a s s e r tTex t I sPre s en t ( ”Design Patterns ”) ;a s s e r tTex t I sPre s en t ( ”Gamma et a l . ”) ;[ . . . ]

}}

Listing 2: Library code example

Executing the test with perform acceptancetests fails.So far there is no production code offering the intended Webapplication. It is relatively easy to pass this test because itmerely deals with simple CRUD functionality. We set up thepersistence layer and create a book entity: entity --class

~.domain.Book. Based on this entity we scaffold the bookmanagement functionality: controller scaffold --class

~.web.BookController --entity ~.domain.Book. Despitethe page for recording a book being implemented, the teststill fails; the domain object does not have the requiredfields. We add the title attribute with field string --

fieldName title -class ~.domain.Book. Likewise we addthe fields author, publisher, year, and isbn. Afterwards,the first acceptance test passes. The functionality was im-plemented by using model-driven means.

Refactoring follows. A failing test during this activitysignals that we broke the test logic. We extract descriptiveconstants from the test data, and extract helper methods.This yields the code shown in Listing 3.

public c lass EnterBookMetadataStories {St r ing VALID TITLE = ”Design Patterns ” ;S t r ing VALID AUTHOR = ”Gamma et a l . ” ;[ . . . ]

@Test public void happyPath ( ) {whenIAddNewBookMetadata (

VALID TITLE , VALID AUTHOR, [ . . . ] ) ;thenIShouldSeeTheRecordedBookData (

VALID TITLE , VALID AUTHOR, [ . . . ] ) ; }

private void whenIAddNewBookMetadata (St r ing t i t l e , S t r ing author , [ . . . ] ) {

open (HOMEPAGE) ;cl ickClickableAndWaitForNextPage (

l inkWithCaption ( ”New book record ”) ) ;typeText IntoText f i e ld ( t i t l e ,

t ex t f i e ldWithLabe l ( ”T i t l e ”) ) ;typeText IntoText f i e ld ( author ,

t ex t f i e ldWithLabe l ( ”Author ”) ) ;[ . . . ]c l ickClickableAndWaitForNextPage (

buttonWithCaption ( ”Save ”) ) ;}

private void thenIShouldSeeTheRecordedBookData (St r ing t i t l e , S t r ing author , [ . . . ] ) {

a s s e r tTex t I sPre s en t ( t i t l e ) ;a s s e r tTex t I sPre s en t ( author ) ;[ . . . ] ) ;

}}

Listing 3: Refactored test code

The next step is to specify requirements for the input data.We execute acceptancetest --story "Invalid ISBN num-

ber" --storyGroup EnterBookMetadata on the Roo shellto create a new test method. We adopt the first acceptancetest, but expect to see an error message (Listing 4).

[ . . . ]S t r ing TOO SHORT ISBN = ”978−020163361 ” ;

@Test public void invalidISBNNumber ( ) {whenIAddNewBookMetadata (

VALID TITLE , [ . . . ] , TOO SHORT ISBN) ;

a s s e r tTex t I sPre s en t (”The ISBN conta ins l e s s than 13 d i g i t s ! ”) ;

}[ . . . ]

Listing 4: Reject ISBN with less than 13 digits

Since no concept ISBN number is provided, this require-ment cannot be implemented with Roo’s model-driven tools.Thus we must extend and adapt the existing functionalitymanually. The concept of ISBN numbers is restricted to theBook class and the components built upon it. It is unlikelythat we need it several times. Thus, building a generatoris not worth the investment. The functionality is locallyadapted in a test-driven manner.

We aim to provide a validation of the isbn field of classBook. Conformable with the use of Bean Validation, wedevelop a custom validator annotation. The first step is cre-ating an IsbnValidator implementing ConstraintValida-

tor<Isbn, String> (Listing 5). Showing the happy-pathand the validation error test at once for conciseness, we pro-vide the needed framework arguments as mock objects [26,35]. For this purpose we employ the Mockito library [19].Tests pass for the IsbnValidator class shown in Listing 6.

public c lass I sbnVal idatorTest {St r ing VALID ISBN = ”978−0201633610 ” ;S t r ing TOO SHORT ISBN = ”978−020163361 ” ;Cons t ra in tV io l a t i onBu i ld e r cns t rVl tB ldr ;

669

Constra intVal idatorContext context ;I sbnVa l idator i sbnVa l ida to r =

new I sbnVa l idator ( ) ;

@Before public void in itMocks ( ) {cns t rVl tB ldr =

mock( Cons t ra in tV io l a t i onBu i lde r . class ) ;context =

mock( Constra intVal idatorContext . class ) ;when( context

. bui ldConstra intVio lat ionWithTemplate (( S t r ing ) any ( ) ) )

. thenReturn ( cns t rVl tB ldr ) ; }

@Test public void accept sVa l id I sbn ( ) {boolean ac tua l =

i sbnVa l ida to r . i sVa l i d (VALID ISBN , context ) ;

a s se r tTrue ( ac tua l ) ;v e r i f y ( context , never ( ) )

. bui ldConstra intVio lat ionWithTemplate (( S t r ing ) any ( ) ) ; }

@Test public void r e j e c t s Sho r t I s bn ( ) {boolean ac tua l =

i sbnVa l ida to r . i sVa l i d (VALID ISBN , context ) ;

a s s e r tFa l s e ( ac tua l ) ;v e r i f y ( context )

. bui ldConstra intVio lat ionWithTemplate (I sbnVa l idator . LESS THAN 13 DIGITS) ;

v e r i f y ( cns t rVl tB ldr ). addConst ra intVio la t ion ( ) ; }

}

Listing 5: Test to reject too short ISBNs

public c lass I sbnVa l idatorimplements Constra intVal idator<Isbn , Str ing> {

St r ing LESS THAN 13 DIGITS =”The ISBN conta ins l e s s than 13 d i g i t s ! ” ;

public void i n i t i a l i z e ( Isbn annotat ion ) {}

public boolean i sVa l i d ( St r ing value ,Constra intVal idatorContext context ) {

i f ( countDig i t s ( value ) < 13) {context

. bui ldConstra intVio lat ionWithTemplate (LESS THAN 13 DIGITS)

. addConst ra intVio la t ion ( ) ;return fa l se ; }

return true ; }

private int countDig i t s ( S t r ing text ) {return t ext . r e p l a c eA l l ( ”[ˆ0−9] ” , ””) . l ength ( ) ;

}}

Listing 6: Implementation of IsbnValidator

Likewise, we could drive checks for more than 13 digits,for null values, and for advanced, algorithmic ISBN con-straints. Finally, we write an annotation (Listing 7) andstick it to the isbn attribute in class Book. After all thislow-level work, our acceptance test passes.

@Target ({ElementType .METHOD, ElementType .FIELD,ElementType .ANNOTATIONTYPE})

@Retention ( Retent ionPol i cy .RUNTIME)@Constraint ( val idatedBy=IsbnVal idator . class )@Documentedpublic @inte r f a ce Isbn {

St r ing message ( ) default ”Enter a va l i d ISBN ! ” ;Class <?>[] groups ( ) default {} ;Class<? extends Payload > [ ] payload ( ) default {} ;

}

Listing 7: The Isbn annotation

The example illustrates how ATDD, MDSD with SpringRoo -and TDD can be combined. Automated acceptance

tests form an unambiguous specification for implementingnew functionality. Simultaneously, the growing set of accep-tance tests prevents regressions. Our Roo add-on facilitatesthe adoption and use of automated acceptance testing. How-ever, since the latter are still plain JUnit tests, syntax andsemantics come natural to Java developers. The investmentand resistance for adoption will be low, and the team canconcentrate on adjusting their development process. Testscan be run without Roo. There is no vendor lock-in.

6. CONCLUSION AND FUTURE WORKWe presented work on the combination of model-driven

and test-driven development of Web applications. It in-cluded evaluating Spring Roo as a development framework.We sketched related work; while many papers exist on thedistinctive approaches, only few combine them. After ex-plaining basics, we explained our development process. Wealso highlighted the connection to acceptance testing. Thefeasibility of our work was shown in an exemplary scenario.

To conclude, using Roo for code generation and incorpo-rating it into a MDSD process driven by acceptance testingis advisable. The combination with TDD is not only pos-sible but a viable option. MDSD increases implementationefficiency. This is aided by the fact that learning to workwith Spring Roo is straightforward since merely knowledgein Java is required. Using ATDD for regression can increaseoverall (external) quality. Finally, TDD increased the inter-nal code quality. Therefore, a combination of the approachesin the improves both effectivity and efficiency.

Our work is not finished. Findings should be evaluatedin industrial software development projects. Ideally, theyshould be verified by a quantitative study. A future targetcould be to describe best practices for combining variousdevelopment paradigms to provide better development pro-cesses. It would be valuable to know whether our findingscan be transferred to other forms of development. Targetsof future research could be other frameworks besides SpringRoo as well as other platforms. For example, developingmobile applications (apps) could be a target of future re-search. Furthermore, we will consider the inclusion of script-ing languages to e.g. increase readability of our tests. Ide-ally, measuring the success of our approach e.g. regardingcost-effectiveness should become possible.

7. REFERENCES[1] Selenium. http://seleniumhq.org/.

[2] S. Abbas and R. M. Samant. Software as a service:shifting businesses to the cloud. In Proc. ICWET ’11,New York, NY, USA, 2011. ACM.

[3] G. Adzic. Specification by example. Manning, 2011.

[4] B. Alex. Spring Roo 1.0.0 Released, 2009.http://blog.springsource.com/2009/12/31/spring-roo-1-0-0-released/.

[5] B. Alex, S. Schmidt, A. Stewart, J. Tyrrell, andA. Swan. Spring Roo - Reference Documentation1.2.0.SNAPSHOT. SpringSource, Inc., 2011.

[6] K. Beck. Embracing change with extremeprogramming. IEEE computer, 32(10):70–77, 1999.

[7] K. Beck. Extreme Programming Explained: EmbraceChange. Addison-Wesley, 2000.

[8] K. Beck. Test-Driven Development: By Example.Addison-Wesley, 2003.

670

[9] K. Beck. Implementation Patterns. Addison-Wesley,2007.

[10] E. Bernard and S. Peterson. JSR 303: BeanValidation, 2009. http://jcp.org/en/jsr/detail?id=303.

[11] D. Bosanac. Scripting in Java. Addison-Wesley, 2007.

[12] M. Campbell-Kelly. Historical reflections: The rise,fall, and resurrection of software as a service.Commun. ACM, 52:28–30, 2009.

[13] G. Canfora, A. Cimitile, F. Garcia, M. Piattini, andC. A. Visaggio. Evaluating advantages of test drivendevelopment: a controlled experiment withprofessionals. In Proc. ESEM ’10, pages 364–371.Springer, 2006.

[14] J. C. Castrejon, R. Lopez-Landa, and R. Lozano.Model2Roo: A model driven approach for webapplication development based on the EclipseModeling Framework and Spring Roo. In Proc. 21stCONIELECOMP, pages 82–87, 2011.

[15] D. Chelimsky, D. Astels, B. Helmkamp, D. North,Z. Dennis, and A. Hellesoy. The RSpec Book.Pragmatic Bookshelf, 2010.

[16] T. Cleff. Basiswissen Testen von Software. W3L, 2010.

[17] M. Cohn. User Stories Applied. Addison-Wesley, 2004.

[18] S. Davis. Groovy Recipes. Pragmatic Bookshelf, 2008.

[19] S. Faber. Mockito, 2011. http://mockito.org/.

[20] A. Fatolahi, S. S. Some, and T. C. Lethbridge.Model-driven web development for multiple platforms.J. Web Eng., 10:109–152, June 2011.

[21] M. Fewster and D. Graham. Software TestAutomation. Addison-Wesley, 1999.

[22] R. T. Fielding. Architectural Styles and the Design ofNetwork-based Software Architectures. PhD thesis,University of California, Irvine, 2000.

[23] P. T. Fisher and B. D. Murphy. Spring Persistencewith Hibernate. Apress, Berkely, CA, USA, 2010.

[24] M. Fowler. Refactoring: Improving the Design ofExisting Code. Addison-Wesley, 1999.

[25] M. Fowler. Patterns of Enterprise ApplicationArchitecture. Addison-Wesley, 2002.

[26] S. Freeman and N. Pryce. Growing object-orientedsoftware, guided by tests. Addison-Wesley, 2009.

[27] E. Gamma, R. Helm, R. Johnson, and J. Vlissides.Design patterns. Addison-Wesley, 1995.

[28] P. Giner and V. Pelechano. Test-driven developmentof model transformations. In Proc. MODELS ’09,pages 748–752, Berlin, 2009. Springer.

[29] R. Gitzel, A. Korthaus, and M. Schader. Usingestablished web engineering knowledge in model-drivenapproaches. Sci. Comput. Program., 66:105–124, 2007.

[30] C. Jones. Software Quality. Thomson Learning, 1997.

[31] L. Koskela. Test Driven: Practical TDD andAcceptance TDD for Java Developers. Manning, 2008.

[32] S. Ladd, D. Davison, S. Devijver, and C. Yates. ExpertSpring MVC and Web Flow. Apress, 2006.

[33] N. Laranjeiro and M. Vieira. Extending test-drivendevelopment for robust web services. In Proc.DEPEND ’09, pages 122–127, Washington, DC, USA,2009. IEEE CS.

[34] J. Long and S. Mayzak. Getting Started with Roo.O’Reilly, 2011.

[35] T. Mackinnon, S. Freeman, and P. Craig.

Endo-testing: Unit testing with mock objects. In XPeXamined. Addison-Wesley, 2000.

[36] G. Mak, D. Rubio, and J. Long. Spring Recipes: AProblem-Solution Approach. Apress, Berkely, CA,USA, 2nd edition, 2010.

[37] R. C. Martin. Clean Code. Prentice Hall PTR, UpperSaddle River, NJ, USA, 2008.

[38] G. Meszaros. XUnit test patterns: refactoring testcode. Addison-Wesley, 2007.

[39] F. P. Miller, A. F. Vandome, and J. McBrewster.Browser wars. Alpha Press, 2009.

[40] N. Nagappan, E. M. Maximilien, T. Bhat, andL. Williams. Realizing quality improvement throughtest driven development: Results and experiences offour industrial teams. Empi. SE, 13(3):289–302, 2008.

[41] C. O. Nutter, T. Enebo, N. Sieger, O. Bini, andI. Dees. Using JRuby. Pragmatic Bookshelf, 2011.

[42] W. F. Opdyke and R. E. Johnson. Refactoring: Anaid in designing application frameworks and evolvingobject-oriented systems. In Proc. SOOPPA, pages145–160, 1990.

[43] D. L. Parnas. Software aging. In Proc. ICSE ’94, pages279–287, Los Alamitos, CA, USA, 1994. IEEE CS.

[44] S. Penchikala. Spring Roo 1.0 M1 Released, 5 2009.

[45] M. Pezze and M. Young. Software testing and analysis:process, principles and techniques. Wiley, 2007.

[46] J. U. Pipka. Test-Driven Web ApplicationDevelopment in Java. In Revised Papers from NODe’02, pages 378–393, London, UK, 2003. Springer.

[47] K. Rimple, S. Penchikala, and G. Dickens. Spring Rooin Action. Manning, 2011.

[48] E. Robles Luna, J. Burella, J. Grigera, and G. Rossi.A flexible tool suite for change-aware test-drivendevelopment of web applications. In Proc. ICSE ’10,pages 297–298, New York, NY, USA, 2010. ACM.

[49] E. Robles Luna, J. Grigera, and G. Rossi. Bridgingtest and model-driven approaches in web engineering.In Proc. ICWE ’09, pages 136–150. Springer, 2009.

[50] E. Robles Luna, J. I. Panach, J. Grigera, G. Rossi,and O. Pastor. Incorporating usability requirements ina test/model-driven web engineering approach. J. WebEng., 9:132–156, June 2010.

[51] A. Sarin. Spring Roo 1.1 Cookbook. Packt Pub., 2011.

[52] A. Schauerhuber, M. Wimmer, and E. Kapsammer.Bridging existing Web modeling languages tomodel-driven engineering: a metamodel for WebML.In Proc. ICWE ’06, New York, NY, USA, 2006. ACM.

[53] D. C. Schmidt. Model-driven engineering. IEEEComputer, 39(2):25–31, 2006.

[54] T. Stahl, M. Voelter, and K. Czarnecki. Model-DrivenSoftware Development. Wiley, 2006.

[55] H. Weinreich, H. Obendorf, E. Herder, and M. Mayer.Not quite the average: An empirical study of Web use.ACM Trans. Web, 2:5:1–5:31, 2008.

[56] S. Wieczorek, A. Stefanescu, M. Fritzsche, andJ. Schnitter. Enhancing test driven development withmodel based testing and performance analysis. InProc. TAIC PART ’08, pages 82–86, Washington, DC,USA, 2008. IEEE CS.

[57] Y. Zhang. Test-driven modeling for model-drivendevelopment. IEEE Softw., 21:80–86, September 2004.

671