Guide to

Testing refactored software

Definition of refactoring

Software applications usually have a long lifetime because it is reused multiple times in different product configurations. So, unfortunately, software “ages”.

This aging is the tendency for software to cause new failures as each change in its surrounding environment introduces a new constraint that wasn’t anticipated with the original design. Organizations refactor their software to meet new requirements, reduce future maintenance costs, and maintain/increase quality.

Benefits of refactoring

Reduce costs
Refactoring improves the maintainability of software. Bugs can be found and fixed faster due to more readable and understandable code. By increasing cohesion and reducing coupling, changes can be implemented demonstrably easier and faster. This reduces costs in the further development and operation of the software.

Examples of refactoring activities

  • Restructuring of software processes to avoid unachievable software conditions (dead code, e.g. unintended defensive programming)
  • Reduction of redundancies (for example outsourcing of same codes segments into a separate function)
  • Replacement of Magic Numbers by parameters
  • Simplification of code components (e.g. resolution of multi-conditions in if statement) in order to achieve easier test coverage
  • Ensuring architecture specifications (e.g. software layers or isolation contracts)

Refactoring preserves the functional behavior of the software before and after a change. The biggest difficulty for the developer is to prove this behavioral equivalence.

 

In theory, there are several ways to show equivalence between the original software and the refactored software:

  • By means of formal proof
  • By means of regression tests

The formal proof method is either very expensive for extensive software projects or nearly impossible to implement. The regression test requires that many test cases for the software already exist.

The alternative approach, coverage testing, is easy to set up and is simple, reliable, understandable and also economical. All you need is a test automation tool that supports Back-to-Back testing and automatic test case generation.

Automatic test case generation enables the developer to evaluate the success of refactoring measures in the worst case, even without existing tests.

Back-to-back testing refers to a method where multiple/different versions of a system/application are available for testing. Both systems are stimulated with identical test cases and the execution results of both are compared.

 ...

 

 

 

Get the full guide to Testing Refactored Software

 

Sign up and read on about Refactoring:

 

  • Definition of successful refactoring
  • Fast approach to checking refactoring
  • Performing refactoring tests in TPT
    • platform setup
    • test case generation including MC/DC
    • test execution and Back-2-Back
  •  

 

Please feel free to contact us.

Author

Robert Fey

Business Development Manager at PikeTec
More than 15 years of experience in automotive software development