Close category search window
 

Test-Oriented Languages: Is it Time for a New Era?

Sign In

Cookies must be enabled to login.After enabling cookies , please use refresh or reload or ctrl+f5 on the browser for the login options.

Formats Non-Member Member
$31 $13
Learn how you can qualify for the best price for this item!
Become an IEEE Member or Subscribe to
IEEE Xplore for exclusive pricing!
close button

puzzle piece

IEEE membership options for an individual and IEEE Xplore subscriptions for an organization offer the most affordable access to essential journal articles, conference papers, standards, eBooks, and eLearning courses.

Learn more about:

IEEE membership

IEEE Xplore subscriptions

1 Author(s)
Stopford, B. ; R. Bank of Scotland, London, UK

More than a decade has passed since the advent of Test Driven Development and the introduction of the tools that facilitate its practice. However, it is our belief that we are nearing the limits through which functional decoration can aid the testing of current imperative languages. This paper presents a thought experiment to explore improvements to the testability of current imperative languages. We use the guise of a hypothetical language, Quilt, to present one path that such a language might take. For brevity we retain the language constructs of current imperative languages like Java and C# and explore alterations in the compiler operation that make the language more test-oriented. Quilt extends the Mockist Test Driven Development approach [2,9] by integrating the role of unit test isolation into the compiler. The application is split into a patchwork of independently testable units. However, unlike current Mocking frameworks [5,11,12], Quilt isolates through the provision of stub Methods, not Objects. Methods that do not return state (or mutate passed references) are automatically stubbed. Methods that do return state cause compilation failures if a stub has not been provided. Through static analysis the compiler minimises the number of interactions that require isolation, reducing coupling between test and class (when compared to current testing practices). The effect is to significantly reduce the barriers to testing: Less test setup is needed, there is no need to inject dependencies for the purpose of testing and even preexisting code is easy to test. We conclude that testing in current object-oriented programming languages is already largely incumbent and ultimately inevitable. However, the penetration of the Mockist approach has been limited somewhat by a high barrier to entry and adverse side effects experienced under certain conditions. We make a case for the value of unit test isolation and describe a mechanism for lowering this barrier for entry, reduci- - ng coupling issues, and generally making TDD easier.

Published in:
Software Testing, Verification and Validation Workshops (ICSTW), 2011 IEEE Fourth International Conference on

Date of Conference: 21-25 March 2011

Need Help?


IEEE Advancing Technology for Humanity About IEEE Xplore | Contact | Help | Terms of Use | Nondiscrimination Policy | Site Map | Privacy & Opting Out of Cookies

A not-for-profit organization, IEEE is the world's largest professional association for the advancement of technology.
© Copyright 2013 IEEE - All rights reserved. Use of this web site signifies your agreement to the terms and conditions.