Ensuring behavioural equivalence in test-driven porting

  • Authors:
  • Mark Hennessy;James F. Power

  • Affiliations:
  • National University of Ireland, Maynooth, Co. Kildare, Ireland;National University of Ireland, Maynooth, Co. Kildare, Ireland

  • Venue:
  • CASCON '06 Proceedings of the 2006 conference of the Center for Advanced Studies on Collaborative research
  • Year:
  • 2006

Quantified Score

Hi-index 0.00

Visualization

Abstract

In this paper we describe the porting of the C++ analysis tool, keystone [1], from C++ to Java using a testing strategy that ensured the correctness of the ported code. Our work extends the eXtreme Porting approach outlined by Varma et al. for porting C/C++ applications [2]. This process operates by porting one class at a time and then unit testing to ensure correctness. We extend this by defining an order for the porting of classes by using an Object Relation Diagram in order to minismise the need for class-stubs during unit-testing.The overall structure of the porting process was as follows:Step 1 The keystone front- and back-end were decoupled. Fortunately the keystone backend classes are easily identified.Step 2 The back-end keystone classes were then ported to Java. This consisted of three steps:Step 2a Dependencies on external libraries were identified. This involved mapping classes in the C++ Standard Template Library, to the Java class library.Step 2b The jKeystone class hierarchy was generated. The class hierarchy of keystone was reverse engineered using an in-house tool, and the corresponding class hierarchy of jKeystone was generated. No method-body code was ported automatically in this step.Step 2c Each class in turn was then manually ported and unit-tested, in the vein of the eXtreme Porting approach.Step 3 keystone's front-end was modified so that when run over a test case, it generated a Java test harness for that test case. These were then used to perform black-box system tests on jKeystone.Step 4 Aspect Oriented Programming was used to weave similar tracing aspects across both keystone and jKeystone. For each test case, the aspected version of keystone and jKeystone produced a sequence diagram, containing the objects and interactions involved in processing that test case. These sequence diagrams were then compared to verify that the behaviour of jKeystone was identical on a per test-case basis.The full version of this paper describes this process in detail, and analyses its impact in terms of its performance and its effectiveness in exposing bugs.