No abstract

Background: Pull-based development has shaped the practice of Modern Code Review (MCR), in which reviewers can contribute code improvements, such as refactorings, through comments and commits in Pull Requests (PRs). Past MCR studies uniformly treat all PRs, regardless of whether they induce refactoring or not. We define a PR as refactoring-inducing, when refactoring edits are performed after the initial commit(s), as either a result of discussion among reviewers or spontaneous actions carried out by the PR developer. Aims: This mixed study (quantitative and qualitative) explores code reviewing-related aspects intending to characterize refactoringinducing PRs. Method: We hypothesize that refactoring-inducing PRs have distinct characteristics than non-refactoring-inducing ones and thus deserve special attention and treatment from researchers, practitioners, and tool builders. To investigate our hypothesis, we mined a sample of 1,845 Apache's merged PRs from GitHub, mined refactoring edits in these PRs, and ran a comparative study between refactoring-inducing and non-refactoring-inducing PRs. We also manually examined 2,096 review comments and 1,891 detected refactorings from 228 refactoring-inducing PRs. Results: We found 30.2% of refactoring-inducing PRs in our sample and that they significantly differ from non-refactoring-inducing ones in terms of number of commits, code churn, number of file changes, number of review comments, length of discussion, and time to merge. However, we found no statistical evidence that the number of reviewers is related to refactoring-inducement. Our qualitative analysis revealed that at least one refactoring edit was induced by review in 133 (58.3%) of the refactoring-inducing PRs examined. Conclusions: Our findings suggest directions for researchers, practitioners, and tool builders to improve practices around pull-based code review.

Manual refactoring edits are error prone, as refactoring requires developers to coordinate related transformations and understand the complex inter-relationship between affected types, methods, and variables. We present RefDistiller, a refactoring-aware code review tool that can help developers detect potential behavioral changes in manual refactoring edits. It first detects the types and locations of refactoring edits by comparing two program versions. Based on the reconstructed refactoring information, it then detects potential anomalies in refactoring edits using two techniques: (1) a template-based checker for detecting missing edits and (2) a refactoring separator for detecting extra edits that may change a program's behavior. By helping developers be aware of deviations from pure refactoring edits, RefDistiller can help developers have high confidence about the correctness of manual refactoring edits. RefDistiller is available as an Eclipse plug-in at https: //sites.google.com/site/refdistiller/ and its demonstration video is available at http://youtu.be/0Iseoc5HRpU.

Power systems rely on ancillary services (ASs) to ensure system security and stability. Until recently, only the conventional power generation resources connected to the transmission grids were allowed to provide these ASs managed by the transmission system operators (TSOs), while distribution system operators (DSOs) had a more passive role, focused on guaranteeing distribution capacity to bring power to final consumers with enough quality. Now, with the decarbonization, digitalization and decentralization processes of the electrical networks, the growing integration of distributed energy resources (DERs) in distribution grids are displacing conventional generation and increasing the complexity of distribution networks’ operation, requiring the implementation of new active and coordinated management strategies between TSOs and DSOs. In this context, DERs are becoming potential new sources of flexibility for both TSOs and DSOs in helping to manage the power system. This paper proposes a systematic characterization of both traditional and potentially new ASs for TSOs, and newly expected DSO local system services to support the new distribution grid operation paradigm, reviewing, in addition, the main TSO-DSO coordination mechanisms.

No abstract

Refactoring edits are error-prone, requiring cost-effective testing. Regression test suites are often used as a safety net for decreasing the chances of behavioural changes. Because of the high costs related to handling massive test suites, prioritization techniques can be applied to reorder test case execution, fostering early fault detection. However, traditional prioritization techniques are not specifically designed for detecting refactoring-related faults. This article proposes refactoring-based approach (RBA), a refactoringaware strategy for prioritizing regression test cases. RBA reorders an existing test sequence, using a set of proposed refactoring fault models that define the refactoring's impact on program methods.Refactoring-based approach's evaluation shows that it promotes early detection of refactoring faults and outperforms well-known prioritization techniques in 71% of the cases.Moreover, it prioritizes fault-revealing test cases close to one another in 73% of the cases, which can be useful for fault localization. Those findings show that RBA can considerably improve prioritization of test cases during perfective evolution, both by increasing fault-detection rates as well as by helping to pinpoint defects introduced by an incorrect refactoring. of refactorings and software bugs [13,14]. In addition, 77% of the participants from the survey of Kim et al. with Microsoft developers [4] confirm that refactoring may induce the introduction of subtle bugs and functionality regression.A number of strategies are designed to prevent behavioural changes when refactoring: (i) refactoring mechanics, proposed by Fowler [1], guide the application of refactoring with the combination of micro changes and compilation/test checks; (ii) the formal specification of refactoring edits, founded by theories of object-oriented programming [15][16][17]; (iii) refactoring engines, automate the application of refactoring edits by checking pre-conditions (e.g. Eclipse ‡ , NetBeans § , JRRT ¶ ); and (iv) regression testing, test suites are used to increase confidence on behaviour preservation after refactoring [18].From those options, regression testing is probably the most popular alternative. However, as a system evolves, its regression test suite tends to increase, because new test cases can be added to check new functionalities [19,20]. Thus, it may be impractical to rerun regression suites after each refactoring when working with a large test suite-it can take a long time for the first test case to fail as well as it may be difficult and costly to gather enough information on test cases that fail so that fault localization can begin. In such context, there is a need for techniques that preserve test effectiveness, with as few test cases as possible. Test case prioritization [21] rearranges a test suite aiming to improve achievement of certain testing goals (e.g. the rate of fault detection). Several prioritization techniques have been proposed [22][23][24][25][26][27][28]; most consider code coverage as prioritization cr...

No abstract

No abstract