{'fraction_non_alphanumeric': 0.013723696248856358, 'fraction_numerical': 0.0, 'mean_word_length': 4.494974874371859, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
Detecting the Methods under Test in Java

Unit tests are a well accepted part of software engineering. JUnit is the de facto standard for unit testing in Java. It collects, organizes and runs tests. Each test focuses on one or several methods. These are called the methods under test. They can be used for a variety of tasks including test navigation, test coverage and test analysis in general. There are no rules for determining on which methods a test focuses. Sometimes it is obvious, but there are cases where we cannot say on which methods a test focuses. Among others we observed two test patterns that look similar but are the inverse of each other. The first consists of an initial setup method and then focuses on one or several methods. The second one invokes the focused method first and then uses accessors to test the side effects. As a result there are no established and foolproof ways to detect the methods under test automatically. In the following we discuss several different, automated ways of detecting the methods under test. Because there are no rules to determine the methods under test, automatically detecting them can never be fully accurate. But we search for different approaches and try to find out how effective they are. First we present several different ways to annotate a test with its methods under test and choose one of them to annotate the tests of some case studies. We also build a tool that allows us to query these methods and their annotations. Afterward we describe ways to automatically detect the methods under test. The first one called NameAnalyzer looks at the names of tests and test cases and uses naming conventions to determine the methods under test. We also parse the source code of a test and try to extract all methods the test directly invokes. Because this results in a lot of false positives we build a heuristic extension to reduce this noise. We run each of these approaches for analysis on some case studies and validate their output against the annotations described in the first section. Finally we discuss these results, judge the approaches by how effective they are in detecting the methods under test, and conclude.