Refactoring test suites versus test behaviour: a TTCN-3 perspective

  • Authors:
  • Steve Counsell;Rob M. Hierons

  • Affiliations:
  • Brunel University, Uxbridge;Brunel University, Uxbridge

  • Venue:
  • Fourth international workshop on Software quality assurance: in conjunction with the 6th ESEC/FSE joint meeting
  • Year:
  • 2007

Quantified Score

Hi-index 0.00

Visualization

Abstract

As a software engineering discipline, refactoring offers the opportunity for reversal of software 'decay' and preservation of a level of software quality. In a recent paper by Zeiss et al. [23], a set of fifteen refactorings were found applicable to Testing and Test Control Notation (TTCN-3) test behaviour and a set of thirteen refactorings to improving the overall structure of a TTCN-3 test suite. All twenty-eight refactorings were taken from the set of seventy-two described in the seminal text by Fowler [10]. An important issue with any refactoring is the testing effort required during implementation of its mechanics. In this paper, we explore the trade-offs between, and the contrasting characteristics of, the two TTCN-3 sets of refactorings from a refactoring mechanics perspective. Firstly, we use a meta-analysis of the same twenty-eight refactorings based on a dependency matrix developed through scrutiny of the mechanics of all seventy-two refactorings in [10] and then an analysis of the refactoring chains emerging from each of the same twenty-eight refactorings. Results suggest that there are compelling reasons for avoiding test suite structure refactorings when the dependencies and chains of the test suite refactorings are considered. Refactoring test behaviour potentially offers a far simpler, less demanding set of tasks required of the developer both from a re-testing and dependency viewpoint.