Fit Refactoring-Improving the Quality of Fit Acceptance Test

Total Page:16

File Type:pdf, Size:1020Kb

Fit Refactoring-Improving the Quality of Fit Acceptance Test FIT REFACTORING-IMPROVING THE QUALITY OF FIT ACCEPTANCE TEST Xu Liu A Thesis Submitted to the graduate college of Bowling Green State University in partial fulfillment of The requirement for the degree of Master of Science August 2007 Committee: Joseph Chao, Advisor Ron Lancaster Mohammad Dadfar ii ABSTRACT Joseph Chao, Advisor Acceptance tests are formal testing conducted to determine whether a system satisfies its acceptance criteria or not and whether the acquirer should accept the system or not. A suite of acceptance tests for large projects might include a large number of test cases; therefore, automation of acceptance test is in great demand. Framework for Integrated Tests (FIT) is a popular tool employed in Agile Software Development to automate acceptance tests. Its most attractive feature is that it uses customer readable tables as test cases so that customers can write test cases. Refactoring is the process of restructuring or rewriting code without changing its interface and functionality. Refactoring make the code easier to read, understand and maintain, and sometime helps to improve the performance of the system. In a typical project that uses FIT as an acceptance test tool, the size of FIT acceptance tests grows as the size of system code grows, and the acceptance design may go far away from the original design (this may happen in any project, not restricted in a project using FIT). At this stage, it would be difficult to read and maintain the FIT acceptance test, and it is time to improve the quality of the acceptance test. In this research, we introduce the concept and reveal the importance of FIT Refactoring. Several FIT Refactoring methods are introduced as examples to show the needs of FIT Refactoring and the methods how it can be accomplished. Of course, the methods given here are some obvious refactoring methods, and new methods can be discovered in further research. We iii also discuss the proper time to do FIT refactoring and proper efforts that should be devoted in it. The similarities and differences between system code refactoring and FIT acceptance test refactoring are also one part of the research. During the research, there are some unexpected findings. One of them is that sometimes, the bad code in FIT acceptance test indicates bad code in the system code. iv ACKNOWLEDGMENTS I would like to give some sincere thanks to my adviser, Dr. Joseph Chao. Without his guidance and support, it would be impossible for me to complete this research. His experience in research, willingness to help and patience are great helps to me. I also want to thank my committee members, Dr. Ron Lancaster and Dr. Mohammad Dadfar for reading and providing valuable suggestions to this research. v TABLE OF CONTENTS Page TABLE OF CONTENTS........................................................................................................ v LIST OF FIGURES .............................................................................................................. vii LIST OF TABLES...............................................................................................................viii LIST OF TABLES...............................................................................................................viii CHAPTER 1 INTRODUCTION.......................................................................................... 1 1.1 Agile Software Development ................................................................................. 1 1.2 Acceptance tests ..................................................................................................... 2 1.3 Framework for integrated tests (FIT) ..................................................................... 3 1.4 Refactoring ............................................................................................................. 8 CHAPTER 2 LITERATURE REVIEW............................................................................. 11 2.1 Acceptance Test and FIT...................................................................................... 11 2.2 Refactoring on System Code and Test Code........................................................ 16 CHAPTER 3 FIT REFACTORING................................................................................... 19 3.1 Why FIT Refactoring ........................................................................................... 19 3.2 Table Refactoring and Fixture Refactoring.......................................................... 21 3.3 When to do FIT Refactoring ................................................................................ 23 CHAPTER 4 METHODS OF FIT REFACTORING ........................................................ 26 4.1 FIT refactoring methods on tables........................................................................ 27 vi 4.1.1 Rename........................................................................................................ 27 4.1.2 Introducing new domain concept ................................................................ 30 4.1.3 Extract similar part of tables into fixture..................................................... 33 4.1.4 Merge tables ................................................................................................ 36 4.1.5 Split table..................................................................................................... 38 4.2 FIT refactoring methods on fixtures..................................................................... 40 4.2.1 Merge similar methods................................................................................ 40 4.2.2 Extract method ............................................................................................ 43 4.2.3 Extract similar methods in fixture into new class ....................................... 45 CHAPTER 5 OTHER FINDINGS..................................................................................... 49 5.1 Improper FIT acceptance test may indicate improper system code ..................... 49 5.2 Recommendation on organization of FIT acceptance test table........................... 51 CHAPTER 6 CONCLUSION............................................................................................ 57 REFERENCES ..................................................................................................................... 59 vii LIST OF FIGURES Figure Page Figure 1-1 FIT acceptance Test Case Sample......................................................................... 5 Figure 1-2 FIT acceptance Test Fixture Sample..................................................................... 6 Figure 1-3 FIT acceptance Test Result Sample ...................................................................... 8 Figure 4-1 Part of AddInventory Fixture.............................................................................. 28 Figure 4-2 AddInventory Fixture Before Refactoring.......................................................... 29 Figure 4-3 AddInventory Fixture After Refactoring ............................................................ 29 Figure 4-4 Refactored purchaseBeverageNew Table ........................................................... 36 Figure 4-5 EditRecipe Fixture Before Refactoring............................................................... 42 Figure 4-6 EditRecipe Fixture Before Refactoring............................................................... 42 Figure 4-7 PurchaseBeverage Before Refactoring ............................................................... 45 Figure 4-8 PurchaseBeverage After Refactoring.................................................................. 45 Figure 4-9 PurchaseBeverage Before Refactoring ............................................................... 46 Figure 4-10 setDefaultRecipes Class.................................................................................... 47 Figure 4-11 purchaseBeverageNew Fixture ......................................................................... 47 Figure 4-12 PurchaseBeverage Test Case............................................................................. 48 Figure 5-1 coffeeMaker Class Diagram................................................................................ 50 Figure 5-2 Part of setUpCoffeeMaker Fixture...................................................................... 50 viii LIST OF TABLES Table Page Table 4-1 Part of AddInventory Test Case ........................................................................... 28 Table 4-2 AddInventory Table Before Refactoring.............................................................. 29 Table 4-3 AddInventory Table After Refactoring ................................................................ 29 Table 4-4 offteredServices Table.......................................................................................... 31 Table 4-5 lineCapability Table ............................................................................................. 31 Table 4-6 The Refactored offeredServices Table ................................................................. 32 Table 4-7 New offteredServices Table ................................................................................. 32 Table 4-8 New offeredServices Table After Refactoring..................................................... 33 Table 4-9 purchaseBeverageNew table ................................................................................ 35 Table 4-10 CalculateCredit table .........................................................................................
Recommended publications
  • Refactoring of Acceptance Tests in Visual Studio
    Refactoring of Acceptance Tests in Visual Studio Denis Elbert Diplomarbeit Studiengang Informatik (Technik) Fakultät für Informatik Hochschule Mannheim Autor: Denis Elbert Matrikelnummer: 510243 Zeitraum: 16.11.2009 – 16.03.2010 Erstgutachterin: Prof. Dr. Astrid Schmücker-Schend Zweitgutachterin Prof. Dr. Miriam Föller-Nord Praktischer Teil angefertigt bei: Prof. Dr. Frank Maurer Agile Software Engineering Group University of Calgary Department of Computer Science 2500 University Dr NW Calgary, Alberta T2N 1N4 Canada Refactoring of Acceptance Tests in Visual Studio STATUTORY DECLARATION (GERMAN) Ich versichere, dass ich die vorliegende Arbeit selbstständig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Alle Stellen, die wörtlich oder sinngemäß aus veröffentlichten und nicht veröffentlichten Schriften entnommen wurden, sind als solche kenntlich gemacht. Die Arbeit hat in dieser oder ähnlicher Form keiner anderen Prüfungsbehörde vorgelegen. Mannheim, 16.03.2010 ________________________ Unterschrift I Refactoring of Acceptance Tests in Visual Studio ABSTRACT Executable Acceptance Test Driven Development (EATDD) is an extension of Test Driven Development (TDD). TDD requires that unit tests are written before any code. EATDD pushes this TDD paradigm to the customer level by using Acceptance Tests to specify the requirements and features of a system. The Acceptance Tests are mapped to a Fixture that permits the automated execution of the tests. With ongoing development the requirements of the system can change. Thus, the Acceptance Tests must be adjusted in order to reflect the new requirements. Since the tests and the corresponding Fixtures must remain consistent, the manual modification of these tests is time consuming and error-prone. Hence comes the need for Acceptance Test refactoring.
    [Show full text]
  • Improving Tools for Javascript Programmers
    Improving Tools for JavaScript Programmers (Position Paper) Esben Andreasen Asger Feldthaus Simon Holm Jensen Aarhus University Aarhus University Aarhus University [email protected] [email protected] [email protected] Casper S. Jensen Peter A. Jonsson Magnus Madsen Aarhus University Aarhus University Aarhus University [email protected] [email protected] [email protected] Anders Møller Aarhus University [email protected] ABSTRACT 2. FINDING ERRORS WITH We present an overview of three research projects that all DATAFLOW ANALYSIS aim to provide better tools for JavaScript web application 1 The TAJS analysis tool infers an abstract state for each programmers : TAJS, which infers static type information program point in a given JavaScript web application. Such for JavaScript applications using dataflow analysis; JSRefac- an abstract state soundly models the possible states that tor, which enables sound code refactorings; and Artemis, may appear at runtime and can be used for detecting type- which provides high-coverage automated testing. related errors and dead code. These errors often arise from wrong function parameters, misunderstandings of the run- time type coercion rules, or simple typos that can be tedious to find using testing. 1. JAVASCRIPT PROGRAMMERS NEED We have approached the development of TAJS in stages. BETTER TOOLS First, our focus has been on the abstract domain and dataflow JavaScript contains many dynamic features that allegedly constraints that are required for a sound and reasonably ease the task of programming modern web applications. Most precise modeling of the basic operations of the JavaScript importantly, it has a flexible notion of objects: properties are language itself and the native objects that are specified in added dynamically, the names of the properties are dynam- the ECMAScript standard [3].
    [Show full text]
  • Pyref: a Refactoring Detection Tool for Python Projects
    Università Software della Institute Svizzera italiana PYREF:AREFACTORING DETECTION TOOL FOR PYTHON PROJECTS Hassan Atwi June 2021 Supervised by Prof. Dr. Michele Lanza Co-Supervised by Dr. Bin Lin SOFTWARE &DATA ENGINEERING MASTER THESIS iii Abstract Refactoring, the process of improving internal code structure of a software system without altering its external behav- iors, is widely applied during software development. Understanding how developers refactor source code can help us gain better understandings of the software development process and the relationship between various versions of software systems. Currently, many refactoring detection tools (e.g., REFACTORINGMINER and REF-FINDER) have been proposed and have received considerable attention. However, most of these tools focus on Java program, and are not able to detect refactorings applied throughout the history of a Python project, although the popularity of Python is rapidly magnifying. Developing a refactoring detection tool for Python projects would fill this gap and help extend the language boundary of the analysis in variant software engineering tasks. In this work, we present PYREF, a tool that automatically detect 11 different types of refactoring operations in Python projects. Our tool is inspired by REFACTORING MINER, the state-of-the-art refactoring detection tool for Java projects. With that said, while our core algorithms and heuristics largely inherit those of REFACTORING MINER, considerable changes are made due to the different language characteristics between Python and Java. PYREF is evaluated against oracles collected from various online resources. Meanwhile, we also examine the reliability of PYREF by manually inspecting the detected refactorings from real Python projects. Our results indi- cate that PYREF can achieve satisfactory precision.
    [Show full text]
  • How Does Object-Oriented Code Refactoring Influence
    How does Object-Oriented Code Refactoring Influence Software Quality? Research Landscape and Challenges Satnam Kaur *1, Paramvir Singh2 1Department of Computer Science and Engineering Dr B R Ambedkar National Institute of Technology, Jalandhar 144011, Punjab, India 2 School of Computer Science University of Auckland, Auckland 1142, New Zealand ABSTRACT Context: Software refactoring aims to improve software quality and developer productivity. Numerous empirical studies investigating the impact of refactoring activities on software quality have been conducted over the last two decades. Objective: This study aims to perform a comprehensive systematic mapping study of existing empirical studies on evaluation of the effect of object-oriented code refactoring activities on software quality attributes. Method: We followed a multi-stage scrutinizing process to select 142 primary studies published till December 2017. The selected primary studies were further classified based on several aspects to answer the research questions defined for this work. In addition, we applied vote-counting approach to combine the empirical results and their analysis reported in primary studies. Results: The findings indicate that studies conducted in academic settings found more positive impact of refactoring on software quality than studies performed in industries. In general, refactoring activities caused all quality attributes to improve or degrade except for cohesion, complexity, inheritance, fault-proneness and power consumption attributes. Furthermore, individual refactoring activities have variable effects on most quality attributes explored in primary studies, indicating that refactoring does not always improve all quality attributes. Conclusions: This study points out several open issues which require further investigation, e.g., lack of industrial validation, lesser coverage of refactoring activities, limited tool support, etc.
    [Show full text]
  • Visual Studio Code
    Visual Studio Code Tips & Tricks Vol. 1 1st Edition – March 2016, Revision 1 (April 2016) © Microsoft 2016 All rights reserved. This document is for informational purposes only. Microsoft Deutschland GmbH · Konrad-Zuse-Str. 1 · D-85716 Unterschleißheim Tel. +49 (0)89 31760 · www.microsoft.com · www.techwiese.de Authors: Tobias Kahlert and Kay Giza · Microsoft Germany Editor: Mathias Schiffer Localization: textoso · www.textoso.com Page 1 of 26 This book expresses the authors’ views and opinions. This document always up-to-date at: http://aka.ms/VSCodeTipsTricks Contents Visual Studio Code? ................................................................................................................................. 4 Preface ..................................................................................................................................................... 5 What is Visual Studio Code? .................................................................................................................... 6 Tip 1 – Getting the Latest and Greatest as a VS Code Insider ................................................................. 6 Tip 2 – Multiple Cursors .......................................................................................................................... 8 Tip 3 – Using the Command Palette to Control VS Code ........................................................................ 8 Tip 4 – Selecting a Language for a File ...................................................................................................
    [Show full text]
  • Introduction to C++: Part 1 Tutorial Version 0.6
    Introduction to C++: Part 1 tutorial version 0.6 Research Computing Services Getting started with the training room terminals . Log on with your BU username . If you don’t have a BU username: . Username: Choose tutm1-tutm18, tutn1-tutn18 . Password: on the board. On the desktop is a link to MobaXterm. Double click to open it. Getting started with the training room terminals . Click the + sign at the top of the window and enter: ssh [email protected] . Use your SCC account if you have one. If not, see the board for a username and password. When prompted enter the password. Getting started on the SCC . Load the Eclipse module: module load eclipse/2019-06 . Enter this command to create a directory in your home folder and to copy in tutorial files: /scratch/intro_to_cpp.sh Run the Eclipse software . Enter this command to start up the Eclipse development environment. eclipse & . When this window appears just click the Launch button: Run the Eclipse software . When this window appears just leave it be for now. Tutorial Outline: All 4 Parts . Part 1: . Part 3: . Intro to C++ . Defining C++ classes . Object oriented concepts . Look at the details of how they . Write a first program work . Part 2: . Part 4: . Using C++ objects . Class inheritance . Standard Template Library . Virtual methods . Basic debugging . Available C++ tools on the SCC Tutorial Outline: Part 1 . Very brief history of C++ . Definition object-oriented programming . When C++ is a good choice . The Eclipse IDE . Object-oriented concepts . First program! . Some C++ syntax . Function calls . Create a C++ class Very brief history of C++ C C++ For details more check out A History of C++: 1979−1991 class Account Object-oriented programming • Internal data: • Balance • Transaction record .
    [Show full text]
  • Test Code Adaptation Plugin for Eclipse
    TAPE Test Code Adaptation Plugin for Eclipse Lehmia Kiran Dr. Fakhar Lodhi Wafa Basit Department of Computer Sciences Department of Computer Sciences Department of Computer Sciences NUCES-FAST NUCES-FAST NUCES-FAST Lahore, Pakistan Lahore, Pakistan Lahore, Pakistan [email protected] [email protected] [email protected] Abstract — Refactoring improves the design of software and Extreme Programming (XP) [14] allows the code to change makes it easier to maintain by eliminating code smells. Manual often; consequently unit tests must also be changed. In refactoring is often error-prone and time-consuming. traditional testing, it is a tester who writes the tests but in Refactoring tools available in almost all major object oriented XP it is developers (not testers) who write tests for every programming languages like java, C++, C# etc that provide class they develop. Whenever refactoring is applied on varying degree of automation. The problem with these tools is that they do not support adaptation of unit tests of the code, many test cases fail due to inconsistency with source refactored code resulting in inconsistent unit tests. Unit tests code. The significant amount of developers’ effort is are the only safety net available to developers to verify the required to manually manipulate the testing suite on every system behavior after refactoring. Once these tests get broken single refactoring [15].The process of refactoring is there is no way to describe whether the system preserved its automated by many tools [17, 20, 21, 22]. Eclipse supports behavior or not. In this paper we provide technical details of automated refactoring and provides separate API to perform TAPE (Test code Adaptation Plug-in for Eclipse).
    [Show full text]
  • Transferring Code-Clone Detection and Analysis to Practice
    Transferring Code-Clone Detection and Analysis to Practice Yingnong Dangy, Dongmei Zhang∗, Song Ge∗, Ray Huang∗, Chengyun Chuy and Tao Xiez ∗Microsoft Research Asia, China Email: {dongmeiz;songge;rayhuang}@microsoft.com yMicrosoft Corporation, USA Email: {yidang,chchu}@microsoft.com zUniversity of Illinois at Urbana-Champaign, USA Email: [email protected] Abstract—During software development, code clones are com- on empirical studies or tool support for detecting or analyzing monly produced, in the form of a number of the same or code clones. However, very few of these research projects were similar code fragments spreading within one or many large conducted in industrial contexts, and much fewer resulting code bases. Numerous research projects have been carried out on empirical studies or tool support for detecting or analyzing research tools were actually used or adopted by industrial code clones. However, in practice, few such research projects practitioners. The research community has already realized have resulted in substantial industry adoption. In this paper, gaps between academic research and industrial practices [6]– we report our experiences of transferring XIAO, a code-clone [8], and has called for training and education of researchers detection and analysis approach and its supporting tool, to and practitioners in conducting successful technology transfer broad industrial practices: (1) shipped in Visual Studio 2012, a widely used industrial IDE; (2) deployed and intensively used and adoption. at the Microsoft Security Response Center. According to our In this paper, we report the successful technology-transfer experiences, technology transfer is a rather complicated journey case of XIAO [9] and lessons learned from our research efforts.
    [Show full text]
  • Comparative Studies of Six Programming Languages
    Comparative Studies of Six Programming Languages Zakaria Alomari Oualid El Halimi Kaushik Sivaprasad Chitrang Pandit Concordia University Concordia University Concordia University Concordia University Montreal, Canada Montreal, Canada Montreal, Canada Montreal, Canada [email protected] [email protected] [email protected] [email protected] Abstract Comparison of programming languages is a common topic of discussion among software engineers. Multiple programming languages are designed, specified, and implemented every year in order to keep up with the changing programming paradigms, hardware evolution, etc. In this paper we present a comparative study between six programming languages: C++, PHP, C#, Java, Python, VB ; These languages are compared under the characteristics of reusability, reliability, portability, availability of compilers and tools, readability, efficiency, familiarity and expressiveness. 1. Introduction: Programming languages are fascinating and interesting field of study. Computer scientists tend to create new programming language. Thousand different languages have been created in the last few years. Some languages enjoy wide popularity and others introduce new features. Each language has its advantages and drawbacks. The present work provides a comparison of various properties, paradigms, and features used by a couple of popular programming languages: C++, PHP, C#, Java, Python, VB. With these variety of languages and their widespread use, software designer and programmers should to be aware
    [Show full text]
  • A Visual Tool-Based Approach to Porting C++ Code
    A VISUAL TOOL-BASED APPROACH TO PORTING C++ CODE. bertjan broeksema Master thesis Rijksuniversiteit Groningen Faculty of mathematics and natural sciences Department Computing Science Supervisor: Prof. dr. A. C. Telea KDAB Supervisors: T. Adam V. Krause Bertjan Broeksema: A Visual Tool-Based Approach to porting C++ Code., Master thesis, © June 2010 ABSTRACT The sheer number of changes needed to port a code base when one of more of its dependencies need to be replaced by either a new version or another framework make it viable to develop tools that perform all or most of the required changes automatically in a reliable way. The purpose of this thesis was to research ways to support developers in the process of automated refactoring of large code bases. To this extent the type of refactoring activities involved was studied. Furthermore, a semi-automated code refactoring system based on queries and rules was developed. Transformations work directly on the source by means of insert and replace actions but are still correct due to the semantic understanding of the code by the framework. Additionally, new visualization techniques are proposed to sup- port the process of iterative refactoring. The results of these are implemented in a tool for the C/C++ language, developed as an extension of the KDevelop Integrated Development Environment (IDE). Finally, the effectiveness and usefulness of the tool was demonstrated on a large industrial code base and concrete refac- toring operations involved in the process of porting C++ code. The tool is able to deal with large and complex code bases. It was tested with a subset of the queries and transformations needed for a Qt3 to Qt4 port on kdelibs 3.5 which contains about 750K lines of code.
    [Show full text]
  • Model-Driven Java Code Refactoring
    Computer Science and Information Systems 12(2):375–403 DOI: 10.2298/CSIS141025015H Model-Driven Java Code Refactoring Sohaib Hamioud1, and Fadila Atil2 1 Complex System Engineering Laboratory (LISCO), Department of Computer Science, Badji Mokhtar University, POB 12, 23000 Annaba, Algeria [email protected] 2 Complex System Engineering Laboratory (LISCO), Department of Computer Science, Badji Mokhtar University, POB 12, 23000 Annaba, Algeria [email protected] Abstract. Refactoring is an important technique for restructuring code to improve its design and increase programmer productivity and code reuse. Performing refactorings manually, however, is tedious, time consuming and error-prone. Thus, providing an automated support for them is necessary. Unfortunately even in our days, such automation is still not easily achieved and requires formal specifications of the refactoring process. Moreover, extensibility and tool develo- pment automation are factors that should be taken into consideration when design- ing and implementing automated refactorings. In this paper, we introduce a model-driven approach where refactoring features, such as code representation, analysis and transformation adopt models as first-class artifacts. We aim at exploring the value of model transformation and code generation when formaliz- ing refactorings and developing tool support. The presented approach is applied to the refactoring of Java code using a prototypical implementation based on the Eclipse Modeling Framework, a language workbench, a Java metamodel and a set of OMG standards. Keywords: code refactoring, metamodeling, model-driven engineering. 1. Introduction Refactoring is the process of changing the internal structure of a software without chan- ging its external behavior, typically aimed at making code more reusable, easier to maintain, easier to extend and easier to understand [3], [19].
    [Show full text]
  • 30 Years of Software Refactoring Research: a Systematic Literature Review
    IEEE TRANSACTIONS OF SOFTWARE ENGINEERING, VOL. 1, NO. 1, JUNE 2020 1 30 Years of Software Refactoring Research: A Systematic Literature Review Chaima Abid, Vahid Alizadeh,Marouane Kessentini, Thiago do Nascimento Ferreira and Danny Dig Abstract—Due to the growing complexity of software systems, there has been a dramatic increase and industry demand for tools and techniques on software refactoring in the last ten years, defined traditionally as a set of program transformations intended to improve the system design while preserving the behavior. Refactoring studies are expanded beyond code-level restructuring to be applied at different levels (architecture, model, requirements, etc.), adopted in many domains beyond the object-oriented paradigm (cloud computing, mobile, web, etc.), used in industrial settings and considered objectives beyond improving the design to include other non-functional requirements (e.g., improve performance, security, etc.). Thus, challenges to be addressed by refactoring work are, nowadays, beyond code transformation to include, but not limited to, scheduling the opportune time to carry refactoring, recommendations of specific refactoring activities, detection of refactoring opportunities, and testing the correctness of applied refactorings. Therefore, the refactoring research efforts are fragmented over several research communities, various domains, and objectives. To structure the field and existing research results, this paper provides a systematic literature review and analyzes the results of 3183 research papers on refactoring covering the last three decades to offer the most scalable and comprehensive literature review of existing refactoring research studies. Based on this survey, we created a taxonomy to classify the existing research, identified research trends, and highlighted gaps in the literature and avenues for further research.
    [Show full text]