Sample

Schnappinger/junit4/org.junit.experimental.max.MaxCore

Human rating uses the original dataset scale.

Human3.79
Lines181

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett00–1; higher is more readable
32.1Δ 11.8
Scalabrino0.7440–1; higher is more readable
47.3Δ 3.4
Dorn0.1580–1; higher is more readable
38.0Δ 5.9
Mi0.0920–1; higher is more readable
10.2Δ 33.7
LLOC59Logical lines; fewer is more readable
35.3Δ 8.6
DeepSeek V4 Pro150–20; mean of three runs
38.0Δ 5.9
GPT-6.1 Sol170–20; mean of three runs
55.3Δ 11.4
BTTF0.3950–1; higher is more readable
33.3Δ 10.6
Human3.791–4; original rating
43.9

Views

Source code

package org.junit.experimental.max; import java.io.File; import java.util.ArrayList; import java.util.Collections; import java.util.List; import junit.framework.TestSuite; import org.junit.internal.requests.SortingRequest; import org.junit.internal.runners.ErrorReportingRunner; import org.junit.internal.runners.JUnit38ClassRunner; import org.junit.runner.Description; import org.junit.runner.JUnitCore; import org.junit.runner.Request; import org.junit.runner.Result; import org.junit.runner.Runner; import org.junit.runners.Suite; import org.junit.runners.model.InitializationError; /** * A replacement for JUnitCore, which keeps track of runtime and failure history, and reorders tests * to maximize the chances that a failing test occurs early in the test run. * * The rules for sorting are: * <ol> * <li> Never-run tests first, in arbitrary order * <li> Group remaining tests by the date at which they most recently failed. * <li> Sort groups such that the most recent failure date is first, and never-failing tests are at the end. * <li> Within a group, run the fastest tests first. * </ol> */ public class MaxCore { private static final String MALFORMED_JUNIT_3_TEST_CLASS_PREFIX = "malformed JUnit 3 test class: "; /** * Create a new MaxCore from a serialized file stored at storedResults * * @deprecated use storedLocally() */ @Deprecated public static MaxCore forFolder(String folderName) { return storedLocally(new File(folderName)); } /** * Create a new MaxCore from a serialized file stored at storedResults */ public static MaxCore storedLocally(File storedResults) { return new MaxCore(storedResults); } private final MaxHistory fHistory; private MaxCore(File storedResults) { fHistory = MaxHistory.forFolder(storedResults); } /** * Run all the tests in <code>class</code>. * * @return a {@link Result} describing the details of the test run and the failed tests. */ public Result run(Class<?> testClass) { return run(Request.aClass(testClass)); } /** * Run all the tests contained in <code>request</code>. * * @param request the request describing tests * @return a {@link Result} describing the details of the test run and the failed tests. */ public Result run(Request request) { return run(request, new JUnitCore()); } /** * Run all the tests contained in <code>request</code>. * * This variant should be used if {@code core} has attached listeners that this * run should notify. * * @param request the request describing tests * @param core a JUnitCore to delegate to. * @return a {@link Result} describing the details of the test run and the failed tests. */ public Result run(Request request, JUnitCore core) { core.addListener(fHistory.listener()); return core.run(sortRequest(request).getRunner()); } /** * @return a new Request, which contains all of the same tests, but in a new order. */ public Request sortRequest(Request request) { if (request instanceof SortingRequest) { // We'll pay big karma points for this return request; } List<Description> leaves = findLeaves(request); Collections.sort(leaves, fHistory.testComparator()); return constructLeafRequest(leaves); } private Request constructLeafRequest(List<Description> leaves) { final List<Runner> runners = new ArrayList<Runner>(); for (Description each : leaves) { runners.add(buildRunner(each)); } return new Request() { @Override public Runner getRunner() { try { return new Suite((Class<?>) null, runners) { }; } catch (InitializationError e) { return new ErrorReportingRunner(null, e); } } }; } private Runner buildRunner(Description each) { if (each.toString().equals("TestSuite with 0 tests")) { return Suite.emptySuite(); } if (each.toString().startsWith(MALFORMED_JUNIT_3_TEST_CLASS_PREFIX)) { // This is cheating, because it runs the whole class // to get the warning for this method, but we can't do better, // because JUnit 3.8's // thrown away which method the warning is for. return new JUnit38ClassRunner(new TestSuite(getMalformedTestClass(each))); } Class<?> type = each.getTestClass(); if (type == null) { throw new RuntimeException("Can't build a runner from description [" + each + "]"); } String methodName = each.getMethodName(); if (methodName == null) { return Request.aClass(type).getRunner(); } return Request.method(type, methodName).getRunner(); } private Class<?> getMalformedTestClass(Description each) { try { return Class.forName(each.toString().replace(MALFORMED_JUNIT_3_TEST_CLASS_PREFIX, "")); } catch (ClassNotFoundException e) { return null; } } /** * @param request a request to run * @return a list of method-level tests to run, sorted in the order * specified in the class comment. */ public List<Description> sortedLeavesForTest(Request request) { return findLeaves(sortRequest(request)); } private List<Description> findLeaves(Request request) { List<Description> results = new ArrayList<Description>(); findLeaves(null, request.getRunner().getDescription(), results); return results; } private void findLeaves(Description parent, Description description, List<Description> results) { if (description.getChildren().isEmpty()) { if (description.toString().equals("warning(junit.framework.TestSuite$1)")) { results.add(Description.createSuiteDescription(MALFORMED_JUNIT_3_TEST_CLASS_PREFIX + parent)); } else { results.add(description); } } else { for (Description each : description.getChildren()) { findLeaves(description, each, results); } } } }

Loading feature diagnosis…

Source regions

Feature contributions

Feature contributions

FeatureValueContribution
(log-odds)
Halstead volumeHow much symbolic information the code contains. It combines the total number of operators and values with the number of distinct ones.5402.875−178.295
Source linesThe number of non-empty source lines.181+72.4
Byte entropyHow varied the bytes in the source text are. Repeated bytes give a lower value; a more even mixture gives a higher value.4.601−6.901

Intercept 8.87 + feature contributions = -103.926 (log-odds).
Score = sigmoid(-103.926) = 0.

Score0.744

Feature contributions

FeatureValueContribution
(log-odds)
Comment layout frequencyHow frequently the layout switches between lines containing only comments or whitespace and lines containing code.181−5.372
Indentation frequencyHow rapidly indentation changes from line to line.135+3.932
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.135−2.677
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.179.901+2.105
Identifier layout (horizontal)How rapidly the visual pattern of identifier characters changes from left to right. It measures spatial frequency, not the meaning of the names.109.972−0.993
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.109.972+0.97
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.067+0.294

Intercept 0.07 + feature contributions = -1.671 (log-odds).
Score = sigmoid(-1.671) = 0.158.

Score0.092
Score59
Run 1

The code has good structure with clear separation of concerns and generally follows one-action-per-line. The class-level Javadoc is excellent, and method-level documentation helps intent. However, readability is hindered by nested anonymous classes (constructLeafRequest), complex string manipulation for malformed JUnit 3 tests, and magic strings scattered throughout. The sortRequest method has a cryptic comment about 'karma points' instead of clear reasoning. findLeaves recursion is reasonably clear, but the special-case handling within it adds cognitive load. Naming is mostly good, though 'each' is used instead of more descriptive names. Overall, the code is maintainable but requires careful reading in several spots due to legacy workarounds and non-obvious conditions.

Run 2

The code is generally well-structured and readable. It uses clear method names, appropriate JavaDoc comments, and maintains a logical flow from public API methods to private helper methods. The class-level documentation explains the sorting algorithm clearly. Methods are concise and focused on single responsibilities. The nesting is shallow, mostly limited to one or two levels. However, a few aspects reduce readability: the comment 'We'll pay big karma points for this' is cryptic and assumes inside knowledge; the anonymous inner class in constructLeafRequest adds complexity; and some string comparison logic (e.g., checking for 'TestSuite with 0 tests') relies on magic strings. The buildRunner method has multiple conditional returns which, while flat, requires careful reading to follow all paths. Overall, the code is maintainable but could benefit from extracting constants and simplifying the runner construction logic.

Run 3

The code is generally well-structured with clear separation of concerns and good use of method extraction. The class-level documentation clearly explains the sorting algorithm. Methods are concise and focused on single responsibilities. However, readability suffers from several issues: the field naming convention (fHistory) is outdated Hungarian notation that reduces clarity; there's excessive Javadoc for trivial methods like run() overloads; some methods mix levels of abstraction (buildRunner has deeply nested conditionals with embedded comments); magic strings like 'TestSuite with 0 tests' and 'warning(junit.framework.TestSuite$1)' obscure intent; and the anonymous inner class in constructLeafRequest disrupts reading flow. The nested conditional logic in findLeaves could be flatter. While the overall architecture is sound, these details prevent higher readability. The code would benefit from replacing magic strings with constants and simplifying the buildRunner method's branching structure.

Run 1

Code Structure: Well-organized methods separate execution, sorting, runner construction, and leaf discovery. Nesting: Most methods are flat with early returns; anonymous classes and recursive traversal introduce moderate nesting. Clarity of intent: Descriptive method names and class documentation explain the sorting strategy, but generic variables such as 'each', string-based special cases, and the vague 'karma points' comment reduce clarity. Code length: Reasonably concise for its responsibilities, although repeated documentation and anonymous-class boilerplate add bulk. Action granularity: Statements generally perform one action per line; a few chained calls and nested constructor expressions require extra parsing. Reading flow: Public entry points lead naturally into supporting helpers, with consistent formatting and sensible delegation. Legacy JUnit compatibility handling interrupts the otherwise straightforward flow.

Run 2

Code Structure: Well organized into small methods separating execution, sorting, runner construction, and leaf traversal. Nesting: Mostly shallow with early returns; anonymous classes and recursive traversal introduce moderate nesting. Clarity of intent: Descriptive method names and class documentation explain the purpose and ordering rules, but string-based detection of special JUnit cases, generic names like 'each', and the vague karma comment reduce clarity. Code length: Reasonably concise for its responsibilities, although repeated documentation and compatibility handling add bulk. Action granularity: Statements generally perform one action per line; a few chained calls and nested constructor expressions require additional parsing. Reading flow: Public entry points naturally lead into helper methods, and formatting is consistent. Legacy edge cases and anonymous runner construction slightly interrupt an otherwise straightforward flow.

Run 3

Code Structure: Well-organized, focused methods separate execution, sorting, runner construction, and tree traversal. Nesting: Mostly shallow with early returns; anonymous classes and recursive leaf handling introduce moderate nesting. Clarity of intent: Descriptive method names and class documentation clearly explain test prioritization, but generic names like 'each', string-based special cases, and the cryptic karma comment reduce clarity. Code length: Generally concise; overloads provide useful delegation, although repeated documentation adds some bulk. Action granularity: Most lines perform one clear action; a few chained calls and nested constructor expressions require additional parsing. Reading flow: Public entry points lead naturally into implementation helpers, with consistent formatting. Legacy JUnit compatibility branches and anonymous runner construction slightly interrupt the otherwise straightforward flow.