![](bg4.png)
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 final result is the business logic implemented,
functionally tested, according to the requirements
specified 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
Specification 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 Specifi-
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
fields 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 Scientific
and Technological Development (CNPq) for financial
support which enabled this study.
REFERENCES
Beck, K. (2003). Test-Driven Development by Example.
Addison-Wesley, first 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, first edi-
tion.
Kilov, H. (1998). Business Specifications: The Key to Suc-
cessful Software Engineering. Prentice Hall, first edi-
tion.
North, D. (2006). Introducing Behavior Driven Develop-
ment. Better Software, first 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).
PROVIDINGFACILITIESFORTHEUSEOFTDDINPRACTICE
245