@proceedings {16563,
	title = {BugsJS: a Benchmark of JavaScript Bugs},
	year = {2019},
	pages = {90-101},
	address = {Xi{\textquoteright}an, China},
	abstract = {JavaScript is a popular programming language that is also error-prone due to its asynchronous, dynamic, and loosely-typed nature. In recent years, numerous techniques have been proposed for analyzing and testing JavaScript applications. However, our survey of the literature in this area revealed that the proposed techniques are often evaluated on different datasets of programs and bugs. The lack of a commonly used benchmark limits the ability to perform fair and unbiased comparisons for assessing the efficacy of new techniques. To fill this gap, we propose BugsJS, a benchmark of 453 real, manually validated JavaScript bugs from 10 popular JavaScript server-side programs, comprising 444k LOC in total. Each bug is accompanied by its bug report, the test cases that detect it, as well as the patch that fixes it. BugsJS features a rich interface for accessing the faulty and fixed versions of the programs and executing the corresponding test cases, which facilitates conducting highly-reproducible empirical studies and comparisons of JavaScript analysis and testing tools.},
	keywords = {benchmark, Bug database, BugsJS, JavaScript, literature survey, real bugs, reproducibility, select:quality},
	doi = {10.1109/ICST.2019.00019},
	url = {https://ieeexplore.ieee.org/document/8730197/authors$\#$authors},
	author = {P{\'e}ter Gyimesi and B{\'e}la Vancsics and Andrea Stocco and Davood Mazinanian and {\'A}rp{\'a}d Besz{\'e}des and Rudolf Ferenc and Ali Mesbah}
}
@article {16565,
	title = {Code Coverage Differences of Java Bytecode and Source Code},
	journal = {Software Quality Journal},
	volume = {27},
	year = {2019},
	month = {03/2019},
	pages = {79-123},
	abstract = {Many software testing fields, like white-box testing, test case generation, test prioritization, and fault localization, depend on code coverage measurement. If used as an overall completeness measure, the minor inaccuracies of coverage data reported by a tool do not matter that much; however, in certain situations, they can lead to serious confusion. For example, a code element that is falsely reported as covered can introduce false confidence in the test. This work investigates code coverage measurement issues for the Java programming language. For Java, the prevalent approach to code coverage measurement is using bytecode instrumentation due to its various benefits over source code instrumentation. As we have experienced, bytecode instrumentation-based code coverage tools produce different results than source code instrumentation-based ones in terms of the reported items as covered. We report on an empirical study to compare the code coverage results provided by tools using the different instrumentation types for Java coverage measurement on the method level. In particular, we want to find out how much a bytecode instrumentation approach is inaccurate compared to a source code instrumentation method. The differences are systematically investigated both in quantitative (how much the outputs differ) and in qualitative terms (what the causes for the differences are). In addition, the impact on test prioritization and test suite reduction{\textemdash}a possible application of coverage measurement{\textemdash}is investigated in more detail as well.},
	keywords = {Code coverage, Coverage tools, Empirical study, Java bytecode instrumentation, select:quality, Source code instrumentation, White-box testing},
	doi = {10.1007/s11219-017-9389-z},
	url = {https://link.springer.com/article/10.1007/s11219-017-9389-z$\#$citeas},
	author = {Ferenc Horv{\'a}th and Tam{\'a}s Gergely and {\'A}rp{\'a}d Besz{\'e}des and D{\'a}vid Tengeri and Gerg{\H o} Balogh and Tibor Gyimothy}
}
@article {16564,
	title = {Differences Between a Static and a Dynamic Test-to-Code Traceability Recovery Method},
	journal = {Software Quality Journal},
	volume = {27},
	year = {2018},
	month = {06/2019},
	pages = {797-822},
	abstract = {Recovering test-to-code traceability links may be required in virtually every phase of development. This task might seem simple for unit tests thanks to two fundamental unit testing guidelines: isolation (unit tests should exercise only a single unit) and separation (they should be placed next to this unit). However, practice shows that recovery may be challenging because the guidelines typically cannot be fully followed. Furthermore, previous works have already demonstrated that fully automatic test-to-code traceability recovery for unit tests is virtually impossible in a general case. In this work, we propose a semi-automatic method for this task, which is based on computing traceability links using static and dynamic approaches, comparing their results and presenting the discrepancies to the user, who will determine the final traceability links based on the differences and contextual information. We define a set of discrepancy patterns, which can help the user in this task. Additional outcomes of analyzing the discrepancies are structural unit testing issues and related refactoring suggestions. For the static test-to-code traceability, we rely on the physical code structure, while for the dynamic, we use code coverage information. In both cases, we compute combined test and code clusters which represent sets of mutually traceable elements. We also present an empirical study of the method involving 8 non-trivial open source Java systems.},
	keywords = {Code coverage, refactoring, select:quality, Structural test smells, Test-to-code traceability, Traceability link recovery, Unit testing},
	doi = {10.1007/s11219-018-9430-x},
	url = {https://link.springer.com/article/10.1007/s11219-018-9430-x},
	author = {Tam{\'a}s Gergely and Gerg{\H o} Balogh and Ferenc Horv{\'a}th and B{\'e}la Vancsics and {\'A}rp{\'a}d Besz{\'e}des and Tibor Gyimothy}
}
@article {SAN17,
	title = {Empirical Study on Refactoring Large-scale Industrial Systems and Its Effects on Maintainability},
	journal = {Journal of Systems and Software},
	volume = {129},
	number = {C},
	year = {2017},
	month = {jul},
	pages = {107{\textendash}126},
	abstract = {We examine hundreds of manual refactoring commits from large-scale industrial systems.We study the effects of these commits on source code using a maintainability model.Developers preferred to fix concrete coding issues rather than fix code smells.A single refactoring had only a small impact (sometimes even negative effect).Whole refactoring process has significant beneficial effect on the maintainability. Software evolves continuously, it gets modified, enhanced, and new requirements always arise. If we do not spend time occasionally on improving our source code, its maintainability will inevitably decrease. The literature tells us that we can improve the maintainability of a software system by regularly refactoring it. But does refactoring really increase software maintainability? Can it happen that refactoring decreases the maintainability? Empirical studies show contradicting answers to these questions and there have been only a few studies which were performed in a large-scale, industrial context. In our paper, we assess these questions in an in vivo context, where we analyzed the source code and measured the maintainability of 6 large-scale, proprietary software systems in their manual refactoring phase. We analyzed 2.5 million lines of code and studied the effects on maintainability of 315 refactoring commits which fixed 1273 coding issues. We found that single refactorings only make a very little difference (sometimes even decrease maintainability), but a whole refactoring period, in general, can significantly increase maintainability, which can result not only in the local, but also in the global improvement of the code.},
	keywords = {Antipatterns, coding issues, ISO/IEC 25010, maintainability, refactoring, select:quality, software quality},
	issn = {0164-1212},
	doi = {10.1016/j.jss.2016.08.071},
	url = {http://www.sciencedirect.com/science/article/pii/S0164121216301558?via\%3Dihub},
	author = {Sz{\H o}ke, G{\'a}bor and Antal, G{\'a}bor and Csaba Nagy and Rudolf Ferenc and Tibor Gyim{\'o}thy}
}
@article {BSC14,
	title = {Empirical Investigation of {SEA}-Based Dependence Cluster Properties},
	journal = {Science of Computer Programming},
	volume = {105},
	year = {2015},
	note = {Special Issue on SCAM{\textquoteright}13},
	pages = {3 - 25},
	publisher = {Elsevier B.V.},
	keywords = {select:quality},
	doi = {http://dx.doi.org/10.1016/j.scico.2014.09.010},
	author = {{\'A}rp{\'a}d Besz{\'e}des and Schrettner, Lajos and Csaba, B{\'e}la and Tam{\'a}s Gergely and Judit J{\'a}sz and Tibor Gyim{\'o}thy}
}
@conference {UHV14,
	title = {Anti-pattern Detection with Model Queries: A Comparison of Approaches},
	booktitle = {Proceedings of the 2014 Software Evolution Week (Merger of the 18th IEEE European Conference on Software Maintenance and Reengineering \& 21st IEEE Working Conference on Reverse Engineering {\textendash} CSMR-WCRE 2014)},
	year = {2014},
	note = {Best paper of the conference},
	pages = {293{\textendash}302},
	publisher = {IEEE Computer Society},
	organization = {IEEE Computer Society},
	address = {Antwerp, Belgium},
	abstract = {Program queries play an important role in several software evolution tasks like program comprehension, impact analysis, or the automated identification of anti-patterns for complex refactoring operations. A central artifact of these tasks is the reverse engineered program model built up from the source code (usually an Semantic Graph, ASG), which is traditionally post-processed by dedicated, hand-coded queries. Our paper investigates the use of the popular industrial Eclipse Modeling Framework (EMF) as an underlying representation of program models processed by three general-purpose model query techniques based on native Java code, local-search and incremental evaluation. We provide in-depth comparison of these techniques on the source code of 17 Java projects using queries taken from refactoring operations in different usage profiles. Our results show that general purpose model queries outperform hand-coded queries by 2-3 orders of magnitude, while there is a 5-10 times increase in memory consumption and model load time. In addition, measurement results of usage profiles can be used as guidelines for selecting the appropriate query technologies in concrete scenarios.},
	keywords = {antipattern detection, program queries, query technologies, select:quality},
	doi = {10.1109/CSMR-WCRE.2014.6747181},
	url = {http://ieeexplore.ieee.org/document/6747181/},
	author = {Ujhelyi, Zolt{\'a}n and Horv{\'a}th, {\'A}kos and Varr{\'o}, D{\'a}niel and Csisz{\'a}r, Norbert Istv{\'a}n and Sz{\H o}ke, G{\'a}bor and L{\'a}szl{\'o} Vid{\'a}cs and Rudolf Ferenc}
}
@conference {16361,
	title = {Empirical investigation of SEA-Based dependence cluster properties},
	booktitle = {IEEE 13th International Working Conference on Source Code Analysis and Manipulation, SCAM 2013},
	year = {2013},
	pages = {1{\textendash}10},
	publisher = {IEEE Computer Society},
	organization = {IEEE Computer Society},
	address = {Piscataway},
	abstract = {Dependence clusters are (maximal) groups of source code entities that each depend on the other according to some dependence relation. Such clusters are generally seen as detrimental to many software engineering activities, but their formation and overall structure are not well understood yet. In a set of subject programs from moderate to large sizes, we observed frequent occurrence of dependence clusters using Static Execute After ({SEA}) dependences ({SEA} is a conservative yet efficiently computable dependence relation on program procedures). We identified potential linchpins inside the clusters; these are procedures that can primarily be made responsible for keeping the cluster together. Furthermore, we found that as the size of the system increases, it is more likely that multiple procedures are jointly responsible as sets of linchpins. We also give a heuristic method based on structural metrics for locating possible linchpins as their exact identification is unfeasible in practice, and presently there are no better ways than the brute-force method. We defined novel metrics and comparison methods to be able to demonstrate clusters of different sizes in programs. {\textcopyright} 2013 {IEEE}.},
	keywords = {select:quality},
	author = {{\'A}rp{\'a}d Besz{\'e}des and Schrettner, L. and B. Csaba and Tam{\'a}s Gergely and Judit J{\'a}sz and Tibor Gyim{\'o}thy},
	editor = {Bram Adams and Juergen Rilling and Foutse Khomh}
}
@conference {6080791,
	title = {A probabilistic software quality model},
	booktitle = {Software Maintenance (ICSM), 2011 27th IEEE International Conference on},
	year = {2011},
	month = {sept.},
	pages = {243 -252},
	keywords = {cost estimation, costing, development cost, IEC standards, ISO standards, ISO/IEC 9126 standard, maintainability, probabilistic software quality model, probability, risk estimation, select:quality, software change, software maintenance, software quality, software quality selected},
	issn = {1063-6773},
	doi = {10.1109/ICSM.2011.6080791},
	author = {Tibor Bakota and P Heged{\H u}s and K{\"o}rtv{\'e}lyesi, P and Rudolf Ferenc and Tibor Gyim{\'o}thy}
}
