PROVIDING FACILITIES FOR THE USE OF TDD IN PRACTICE

Vin

ıcius Pereira and Antonio Francisco do Prado

Department of Computing, Federal University of Sao Carlos, Sao Carlos, Brazil

Keywords:

Functional Testing, Test Case Generation, Code Transformation, Test Driven Development, User Stories,

Test, User Acceptance Testing, Scrum.

Abstract:

In this paper we describe an approach that provides a way to facilitate the use of TDD in the practice of

Web application development, independent of the development process used. As an example, it is presented

a way of integrating the functional testing (on level of acceptance) in the Scrum process. The functional tests

are constructed to test the User Stories, which represent the software requirements speciﬁed in the Product

Backlog according to the Scrum. The approach is divided into three stages: Tests Speciﬁcation, Functional

Tests Construction and Tests Driven Implementation. An example of social application illustrates the use of

the proposed approach.

1 INTRODUCTION

In the context of software engineering, software test-

ing is considered a priority activity (Bertolino, 2007).

This is due to the fact that a defect found when the

software is in production may have a much higher cost

to ﬁx than if the same were found in the early stages

(Perry, 2006).

In this paper we present an approach that aims to

provide facilities for the practical use of Test Driven

Development (Beck, 2003) in software development.

To exemplify the use of this approach is shown how

to integrate functional testing with the Scrum pro-

cess, aiming to combine the advantages of agility and

knowledge of this agile method to the of Tests which

aim to reduce the mistakes of inconsistent implemen-

tations with the requirements speciﬁed for the soft-

ware.

The proposed approach, which emerged during

the RAMBUS process improvements (Pereira and

do Prado, 2011) (a variation of Scrum), of the same

authors, aims to improve software quality without los-

ing the agility of the Scrum. Based on the User Sto-

ries (Cohn, 2004), the integration of functional testing

helps the development team on the task of implement-

ing the software in a manner more consistent with

their requirements. For the tests to simulate the func-

tionality of the software, a test speciﬁcation language

was developed and a converter was built to generate,

based on these speciﬁcations, the test code in the tar-

get language of the software implementation.

In the following section we present the proposed

approach. And the section 3 presents the conclusions

and future work.

2 THE PROPOSED APPROACH

The explanation of the proposed approach shows how

to integrate its three stages with the Scrum process

to create functional tests. The three stages are: Test

Speciﬁcation, Functional Test Construction and Test

Driven Implemantation. These stages are present in

each Scrum Sprint, as shown in Figure 1, and are per-

formed for each of the User Story.

The approach is based on the TDD concepts of “to

create a test, check its failure, write the code for the

test to be approved” and the concept to develop driven

by the expected behavior of software. To assist the un-

derstanding and the inter-relationship of these three

stages, Figure 2 shows in a SADT diagram (Struc-

tured Analysis and Design Technique) (Ross, 1977)

the inputs and the outputs of each stage, as well as

their respective mechanisms and controls.

In the following, the stages of the approach are

presented in more detail. To facilitate understanding,

it is used as an example the development of an ap-

plication domain of social network. This application

integrates Facebook

and Google+

features and

https://www.facebook.com/

https://plus.google.com/

242

Pereira V. and Francisco do Prado A..

PROVIDING FACILITIES FOR THE USE OF TDD IN PRACTICE.

DOI: 10.5220/0003906302420245

In Proceedings of the 8th International Conference on Web Information Systems and Technologies (WEBIST-2012), pages 242-245

ISBN: 978-989-8565-08-2

 2012 SCITEPRESS (Science and Technology Publications, Lda.)

Figure 1: Scrum and Functional Testing.

Figure 2: SADT of the proposed approach.

aims to be a social networking site with a focus on

build and reﬂect social networks and social relations

between people. The functional tests created in this

example are in the acceptance testing level.

Tests Speciﬁcation: at this stage, based on the Story

Cards and Mockups, the development team should

write the User Story using the Test Speciﬁcation Lan-

guage (TSL).

Created by the authors, this language has some

minor modiﬁcations made to the structure of the User

Story provided by Mike Cohn (Cohn, 2004), towards

implementing in C# (the chosen target language). In-

stead of double quotes (“ ”), the symbol “$” was used

to reference identiﬁers (ﬁelds, variables, and buttons)

and braces ({ }) were used to indicate strings. If

necessary, the TSL grammar can be easily modiﬁed,

making it more appropriate to specify the User Sto-

ries. The Figure 3 shows an example of an User Story

for a social network application deﬁned using TSL.

PROVIDINGFACILITIESFORTHEUSEOFTDDINPRACTICE

243

Figure 3: User Story written in TSL.

Functional Tests Construction: in this second stage,

the development team uses the User Story written in

TSL created in the previous stage to create a business

rule instrumented with functional test. This stage is

aided by Story2CSharp Converter, which converts the

TSL for the C# language. This converter was devel-

oped by the authors to support the approach together

with the TSL.

Operationally, the development team copies the

contents of the User Story described in TSL (or

even write the contents) to the left screen of the

Story2CSharp Converter. The converter generates the

C# code in execution time and displays it on the right

screen. The Figure 4 shows the converter with a iter-

ation button created when needed. In this moment,

with the User Story being written in the converter

screen, the next line should begin with the keyword

“Given”. The Figure 5 shows the conversion result of

the User Story in Figure 3 to the functional test in C#.

Figure 4: The Story2CSharp Converter in action.

As shown in Figure 5, it was generated a test

class with the name indicating the use of the library

Story2CSharp and each story becomes a testable

method. It is important to note that although con-

verted to C#, the Story is perfectly legible in order

to maintain a level of abstraction close to that offered

by TSL.

Next is created a variable Story which will con-

tain the information of the User Story. The contents

of each scenario is divided into methods that are de-

clared externally in relation to the testable method.

Figure 5: User Story, of the Figure 3, as functional test in

C#.

The name of each method is deﬁned to indicate with

an underscore ( ) where their attributes ﬁt the name

for easier its reading. These methods are designed

with the goal of throwing an exception to indicate that

they have not yet been implemented. At the end of the

testable method, an internal function is called to exe-

cute the Story.

Thus, the development team builds the functional

test integrated with the User Story. Note that the

business logic is not automatically generated. Only

the structure of the test is generated, leaving the

writing of the logic to the next stage of the approach.

Tests Driven Implementation: in this last stage, the

functional test generated in the previous stage should

guide the coding of business logic, following the prin-

ciples of BDD (North, 2006). Other codes may have

been created automatically or not, to support this

stage of the approach, such as the creation of CRUD

(Kilov, 1998) and the database.

In the Visual Studio environment, the approach is

supported by VS Unit Test and NUnit testing frame-

works as well the library Story2CSharp. The devel-

opment team includes the code generated by the con-

verter in the project created in Visual Studio.

WEBIST2012-8thInternationalConferenceonWebInformationSystemsandTechnologies

244

Once the functional test was constructed, the de-

velopment team can execute it and analyze its results.

Because the code has just been generated, the most

likely outcome is that the functional test is “incon-

clusive”, since the methods of each scenario are yet

structures that were not implemented. The Figure 6

shows this result.

Figure 6: Result showing that the functional test was incon-

clusive, due to pending methods.

Following, the development team writes the code

to test the business logic of the User Story so that its

steps accuse failures. To correct the failures, the de-

velopment team implements the business logic for the

steps that be approved in the tests.

The use of this approach does not preclude the use

of unit testing. The use of these tests help to com-

plement the evaluation of the User Story. A way to

integrate the unit testing with functional testing can

be found in the Chelimsky’s book (Chelimsky et al.,

2010).

The ﬁnal result is the business logic implemented,

functionally tested, according to the requirements

speciﬁed in the User Story. Similarly the approach

is repeated for the others User Stories in each Scrum

Sprint.

3 CONCLUSIONS

The proposed approach helps in software creation by

guiding the development based on the behavior ex-

pected by the user. This is possible through the im-

plementation of the User Stories written in a Tests

Speciﬁcation Language (TSL), which has a high level

of abstraction. These stories are the basis of the ap-

proach, describing each business rule as a Story Card

and ending as Functional Tests. These tests are in the

acceptance testing level and are executed to guide the

implementation. This approach can be used by any

development process, regardless of whether or not

Agile. It is only necessary that the development team

makes use of concepts and techniques of Test Driven

Development.

The approach was tested in social networking appli-

cations, as the presented on this paper. Two tools were

developed to support the approach: the Tests Speciﬁ-

cation Language (TSL), written as a DLL to be used

with the Visual Studio and the Story2CSharp Con-

verter, which uses the DLL and assists in achieving

the functional test from the User Story written in TSL.

Future work includes case studies to test the pro-

posed approach. Also includes the improvement of

tools for importing directly from C# code for Visual

Studio and the realization of new case studies in other

ﬁelds of application.

ACKNOWLEDGEMENTS

The authors would like to thanks to the people from

their laboratory for their support and cooperation.

Thanks also to The National Council for Scientiﬁc

and Technological Development (CNPq) for ﬁnancial

support which enabled this study.

REFERENCES

Beck, K. (2003). Test-Driven Development by Example.

Addison-Wesley, ﬁrst edition.

Bertolino, A. (2007). Software testing research: Achieve-

ments, challenges, dreams. In Future of Software En-

gineering, pages 85 – 103, Washington, DC, USA.

Chelimsky, D., Astels, D., Dennis, Z., Hellesoy, A.,

Helmkamp, B., and North, D. (2010). The RSpec

Book: Behaviour-Driven Development with RSpec,

Cucumber, and Friends. Pragmatic Bookshelf, beta

edition.

Cohn, M. (2004). User Stories Applied: For Agile Software

Development. Addison-Wesley Professional, ﬁrst edi-

tion.

Kilov, H. (1998). Business Speciﬁcations: The Key to Suc-

cessful Software Engineering. Prentice Hall, ﬁrst edi-

tion.

North, D. (2006). Introducing Behavior Driven Develop-

ment. Better Software, ﬁrst edition.

Pereira, V. and do Prado, A. F. (2011). Rambus: An agile

process for developing web applications. Journal of

Intelligent Computing, volume 2:42–53.

Perry, W. (2006). Effective methods for software testing.

John Wiley and Sons, third edition.

Ross, D. T. (1977). Structured Analysis: A Language for

Communicating Ideas, pages 16–34. IEEE Transac-

tions on Software Engineering 3(1).

PROVIDINGFACILITIESFORTHEUSEOFTDDINPRACTICE

245