REFactoring and TESTing ('REFTEST') Network

重构和测试（“REFTEST”）网络

• 批准号: EP/G031126/1
• 负责人: Steve Counsell
• 金额: $ 6.74万
• 依托单位: Brunel University London
• 依托单位国家: 英国
• 项目类别: Research Grant
• 财政年份: 2009
• 资助国家: 英国
• 起止时间: 2009 至 无数据
• 项目状态: 已结题
• 来源: https://gtr.ukri.org/projects?ref=EP%2FG031126%2F1
• 关键词: REFactoring; TESTing; REFTEST; Network

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.

所有类型的计算机系统都会随着年龄的增长和体积的增大而质量下降。随着开发人员将越来越多的更改作为系统维护的一部分应用到系统中(通过故障的发生或用户的更改请求)，其最终结果通常是使系统更难维护，并随之而来的是在同一系统中投资更多故障的风险。以这种方式衰退的系统已被称为“代码衰变”。一种试图扭转这种衰退的技术是重构。重构指的是以这样一种方式改变系统的过程：系统不改变它做什么，而只是改变它做它的方式。例如，开发人员可以做的最简单的重构之一就是重命名代码构件，以便使该构件的用途更加清晰。另一种重构可能会将过大的代码构件一分为二，从而使系统更易于管理。因此，重构的好处包括更易理解的代码，但更重要的是，对开发人员来说，未来的工作要容易得多。许多不同的开发人员可能需要查看并更改该代码，以便使该代码尽可能易于理解。在开发人员对系统进行任何更改(或更改集)之后，必须对其进行测试，以确保正确应用更改；重要的是确保相同的更改不会对系统的其他部分产生不利影响。一个衰败和增长的系统的一个缺点是，随着系统的碎片化，开发人员进行了更改后，需要应用越来越多的测试。这给开发人员带来了负担。更改代码是非常耗时的；必须测试系统也会使所需的工作加倍。正如我们已经说过的，重构的好处是更易于理解和管理的代码。如果实现了这一点，那么自然会减少测试负担，因为进行的更改更有效；此外，系统的其他部分产生“副作用”导致故障的机会也更少；最后，随着时间的推移，系统在大小和可管理性方面的总体“稳定性”也会增加。尽管我们对作为独立活动的重构和测试了解很多，但有许多与这两个领域之间的联系相关的开放研究问题。事实上，这个问题已经回到了原点。测试系统的代码(测试通常也是计算机程序)正变得比实际测试的代码更难维护！更有趣的是，最近我们已经成功地将重构应用于日常生活中使用的信息系统。有大量的机会将重构原则应用于测试代码本身，即不仅应用于应用程序代码，而且测试该应用程序的代码。第一，刚才提到的重构测试代码的机会和好处；第二，重构和测试之间联系的理论方面--因为所有健全的实际工作都依赖于同样健全的理论基础。例如，一些重构是否比其他重构更“复杂”？如果是的话，复杂程度有多大？第三，我们能否从真实世界的系统中收集“经验”数据，以确定重构应用程序和测试代码的益处程度？这些是REFTEST网络将解决并总结研究的研究问题。

项目成果

Is a strategy for code smell assessment long overdue?

• DOI: 10.1145/1809223.1809228
• 发表时间: 2010-05
• 作者: S. Counsell;R. Hierons;H. Hamza;S. Black;M. Durrand

Exploring the Eradication of Code Smells: An Empirical and Theoretical Perspective

• DOI: 10.1155/2010/820103
• 发表时间: 2010
• 期刊: Adv. Softw. Eng.
• 作者: S. Counsell;R. Hierons;H. Hamza;S. Black;M. Durrand