| EPSRC Reference: |
EP/G031126/1 |
| Title: |
REFactoring and TESTing ('REFTEST') Network |
| Principal Investigator: |
Counsell, Professor SJ |
| Other Investigators: |
|
| Researcher Co-Investigators: |
|
| Project Partners: |
|
| Department: |
Information Systems Computing and Maths |
| Organisation: |
Brunel University London |
| Scheme: |
Network |
| Starts: |
09 June 2009 |
Ends: |
08 June 2012 |
Value (£): |
52,878
|
| EPSRC Research Topic Classifications: |
|
| EPSRC Industrial Sector Classifications: |
|
| Related Grants: |
|
| Panel History: |
| Panel Date | Panel Name | Outcome |
|
21 Oct 2008
|
ICT Prioritsation Panel (Oct 2008)
|
Announced
|
|
|
Summary on Grant Application Form |
|
Computer systems of all types tend to deteriorate in quality as they age and grow larger. As more and more changes are applied to a system by developers as part of system maintenance (either through the occurrence of a fault or change requests by the users) the net effect is usually to render the system more difficult to maintain and, with it, the risk of investing more faults in the same system. The decline of a system in this way has come to be known as 'code decay'. A technique that attempts to reverse that decay is refactoring. Refactoring refers to a process where a system is changed in such a way that the system does not change 'what' it does, it just changes the 'way' it does it. For example, one of the simplest refactorings that a developer can do is to rename a code artefact so that the purpose of that artefact is made clearer. Another refactoring may split an excessively large code artefact into two so that the system is more manageable as a result. The benefits of refactoring therefore include more understandable code, but, more significantly, in a far easier job in the future for developers. Many different developers may need to look at and change that code so it make sense to make that code as easily understood as possible. After any change (or set of changes) is made by a developer to a system, it has to be tested to ensure that the change has been applied correctly; as important is to ensure that the same change has not adversely affected other parts of the system. One down side of a decaying and growing system is that more and more tests need to be applied after a change has been made by a developer as the system fragments. This places a burden on the developer. Making a change to code is time-consuming enough; having to test the system as well doubles the effort required. The benefits of refactoring are, as we have said, more understandable and more manageable code. If that is achieved, then there naturally follows a reduction in the testing burden, since changes are made more effectively; moreover, there are less opportunities for 'side-effects' in other parts of the system causing faults; finally there is the added benefit of a general 'stability' to the system in size and manageability as it evolves over time. Although we know much about refactoring and testing as independent activities, there are many open research issues related to the link between the two areas. In fact, the problem has turned full-circle. The code that tests the system (tests are often computer programs as well) is becoming more difficult to maintain than the code it actually tests! Even more interestingly, we have been successfully applying refactorings in the recent past to information systems used in every day life. There is a vast amount of opportunity for applying refactoring principles to the test code itself, i.e., not only to the application code, but the code that tests that application.The purpose of the proposed research is to investigate the link between these two areas from three perspectives. Firstly, opportunities for, and benefits of, refactoring of the test code as just mentioned; secondly, the theoretical aspects of the link between refactoring and testing - since all sound practical work relies on an equally sound theoretical basis. For example, are some refactorings more 'complex' than others and, if so, by how much? Thirdly, can we collect 'empirical' data from real-world systems to determine the extent of the benefits of refactoring both applications and test code? These are the research questions that the REFTEST Network will address and summarises the research.
|
|
Key Findings |
|
This information can now be found on Gateway to Research (GtR) http://gtr.rcuk.ac.uk
|
|
Potential use in non-academic contexts |
|
This information can now be found on Gateway to Research (GtR) http://gtr.rcuk.ac.uk
|
|
Impacts |
|
| Description |
This information can now be found on Gateway to Research (GtR) http://gtr.rcuk.ac.uk |
| Summary |
|
| Date Materialised |
|
|
|
|
Sectors submitted by the Researcher |
|
This information can now be found on Gateway to Research (GtR) http://gtr.rcuk.ac.uk
|
| Project URL: |
|
| Further Information: |
|
| Organisation Website: |
http://www.brunel.ac.uk |