A TTCN-3 Refactoring Catalog
This catalogue of refactorings for TTCN-3 has been first published in Benjamin Zeiß: "A Refactoring Tool for TTCN-3". Based on this, an updated TTCN-3 refactoring catalog is maintained using this Wiki.
The refactorings are presented in the form of a catalog which is inspired by the catalog in Martin Fowler's Refactoring Book. Hence, the same fixed format is used for the refactoring descriptions: each refactoring is described by its name, a summary, a motivation, mechanics and an example. The mechanics contain precise step by step instructions on how to perform the refactoring. The mechanics can be used as a manual step-by-step instruction for predictable restructuring or as a guide for tool implementation. Since manual refactorings are error-prone, the mechanics contain instructions compile and validate. The compile step is used to check whether syntax and static semantics of the test cases are still valid. The validate step means to check that the behaviour of the test has not changed. This means to start a bisimulation process (i.e. validation of test equivalence using all possible execution paths) to validate that original and refactored test suite still behave equivalently. The compile and validate steps are suggested as soon and as often as they are applicable. Since some of the refactorings from this catalog are automated by TRex, you do not need to care about the mechanics and the compile and validate steps if you apply these refactorings using TRex.
General Refactorings Applied to TTCN-3
In this section a list of classical refactorings is presented which can be applied to TTCN-3. For this purpose, all 72 refactorings from Martin Fowler's Refactoring Book have been investigated for their relevance. Even though they were intended for Java, some of them are language independent or can be reinterpreted in a way that they are applicable to TTCN-3. For their reinterpretation, it is necessary to replace the notion of Java methods by TTCN-3 functions or test cases. As TTCN-3 lacks most important object-oriented features in the conventional sense (e.g. classes, polymorphism), many well known refactorings cannot be applied. However, some of the Java refactorings are nevertheless applicable if the notion of Java classes and fields is replaced by TTCN-3 component types and variables, constants, timers and ports local to the component respectively.
There are some refactorings which can be applied in the TTCN-3 language, but lack a comparable code improving effect. The Encapsulate Collection refactoring, for example, could surely be applied by wrapping access to an array, for instance, in functions on a module level (instead of classes). However, the use would be limited as array sizes can only be assigned at declaration and if there is really a demand to hide internal data structures, it is likely the language is used in the wrong context. Therefore, such borderline cases are omitted within this list of reinterpreted refactorings.
As a complete catalog would be a book in itself, the extent of the following section is limited to one exemplary refactoring (Extract Function) and a list of the ones working. Hence, the links in Section TTCN-3 Compatible Classical Refactorings refer to directly to Fowler's online refactoring catalog, whereas the links in Section TTCN-3 Specific Refactorings refer to our own TTCN-3 refactoring catalog.
TTCN-3 Compatible Classical Refactorings
In the following, a list of 28 refactorings from Martin Fowler's Refactoring Catalog is presented which can be applied to TTCN-3 with only little or no modification apart from syntactical differences. If a reinterpretation is needed, the original name is given in brackets:
Refactoring for Test Behavior
- Consolidate Conditional Expression
- Consolidate Duplicate Conditional Fragments
- Decompose Conditional
- Extract Function (Extract Method)
- Introduce Assertion
- Introduce Explaining Variable
- Inline Function (Inline Method)
- Inline Temp
- Remove Assignments to Parameters
- Remove Control Flag
- Replace Nested Conditional with Guard Clauses
- Replace Temp with Query
- Separate Query From Modifier
- Split Temporary Variable
- Substitute Algorithm
Refactorings for Improving the Overall Structure of a Test Suite
- Add Parameter
- Extract Extended Component (Extract Subclass)
- Extract Parent Component (Extract Superclass)
- Introduce Local Port/Variable/Constant/Timer (Introduce Local Extension)
- Introduce Record Type Parameter (Introduce Parameter Object)
- Parameterize Testcase/Function/Altstep (Parameterize Method)
- Pull Up Port/Variable/Constant/Timer (Pull Up Field)
- Push Down Port/Variable/Constant/Timer (Push Down Field)
- Replace Magic Number with Symbolic Constant
- Remove Parameter
- Rename (Rename Method) (Note: Fowler refers only to renaming a method. However, not only corresponding altsteps, test cases and functions qualify for renaming, but also variables, types, constants, ports, etc.)
- Replace Parameter with Explicit Functions (Replace Parameter with Explicit Methods)
- Replace Parameter with Function (Replace Parameter with Method)
TTCN-3 Specific Refactorings
In the following, refactorings are introduced which are specific to TTCN-3. While the refactorings presented in the previous section were essentially language independent, the ones presented in this section consider language constructs specific to TTCN-3 such as altsteps, templates, grouping, modules and importing from modules, components, restricted sub-types, logging and concurrent test cases:
Refactoring for Test Behavior
- Extract Altstep
- Split Altstep
- Replace Altstep with Default (Updated)
- Add Explaining Log
- Distribute Test
Refactorings for Data Descriptions
- Inline Template
- Inline Template Parameter
- Extract Template
- Replace Template with Modified Template
- Collapse Templates? (merge template that is modified by another template and only referenced by this modified template into one) (New, but not elaborated, yet.)
- Merge Template
- Parameterize Template
- Remove Duplicate Template
- Decompose Template
- Subtype Basic Types
Refactorings for Improving the Overall Structure of a Test Suite
- Extract Module / Move Declarations to Another Module
- Group Fragments
- Restrict Imports
- Prefix Imported Declarations
- Parameterize Module
- Move Module Constants to Component
- Move Local Variable/Constant/Timer to Component
- Move Component Variable/Constant/Timer to Local Scope
- Generalize Runs On
Note: Some of the refactorings which replace two are more definitions by a single definition (e.g. Merge Template) do currently not take into account whether the removed definitions are imported elsewhere or the new single definition is now located in a different scope or group and thus corresponding imports are not properly adjusted!
