Sample

Schnappinger/junit4/junit.framework.TestResult

Human rating uses the original dataset scale.

Human3.93
Lines185

Scores

MethodScoreScaleDataset rank
(0–100)
Posnett00–1; higher is more readable
42.1Δ 17.6
Scalabrino0.8870–1; higher is more readable
84.9Δ 25.2
Dorn0.3170–1; higher is more readable
48.8Δ 10.9
Mi0.6350–1; higher is more readable
70.3Δ 10.6
LLOC65Logical lines; fewer is more readable
33.2Δ 26.6
DeepSeek V4 Pro17.670–20; mean of three runs
83.0Δ 23.3
GPT-6.1 Sol180–20; mean of three runs
73.8Δ 14.0
BTTF0.6340–1; higher is more readable
63.7Δ 4.0
Human3.931–4; original rating
59.7

Views

Source code

package junit.framework; import java.util.ArrayList; import java.util.Collections; import java.util.Enumeration; import java.util.List; /** * A <code>TestResult</code> collects the results of executing * a test case. It is an instance of the Collecting Parameter pattern. * The test framework distinguishes between <i>failures</i> and <i>errors</i>. * A failure is anticipated and checked for with assertions. Errors are * unanticipated problems like an {@link ArrayIndexOutOfBoundsException}. * * @see Test */ public class TestResult { protected List<TestFailure> fFailures; protected List<TestFailure> fErrors; protected List<TestListener> fListeners; protected int fRunTests; private boolean fStop; public TestResult() { fFailures = new ArrayList<TestFailure>(); fErrors = new ArrayList<TestFailure>(); fListeners = new ArrayList<TestListener>(); fRunTests = 0; fStop = false; } /** * Adds an error to the list of errors. The passed in exception * caused the error. */ public synchronized void addError(Test test, Throwable e) { fErrors.add(new TestFailure(test, e)); for (TestListener each : cloneListeners()) { each.addError(test, e); } } /** * Adds a failure to the list of failures. The passed in exception * caused the failure. */ public synchronized void addFailure(Test test, AssertionFailedError e) { fFailures.add(new TestFailure(test, e)); for (TestListener each : cloneListeners()) { each.addFailure(test, e); } } /** * Registers a TestListener */ public synchronized void addListener(TestListener listener) { fListeners.add(listener); } /** * Unregisters a TestListener */ public synchronized void removeListener(TestListener listener) { fListeners.remove(listener); } /** * Returns a copy of the listeners. */ private synchronized List<TestListener> cloneListeners() { List<TestListener> result = new ArrayList<TestListener>(); result.addAll(fListeners); return result; } /** * Informs the result that a test was completed. */ public void endTest(Test test) { for (TestListener each : cloneListeners()) { each.endTest(test); } } /** * Gets the number of detected errors. */ public synchronized int errorCount() { return fErrors.size(); } /** * Returns an Enumeration for the errors */ public synchronized Enumeration<TestFailure> errors() { return Collections.enumeration(fErrors); } /** * Gets the number of detected failures. */ public synchronized int failureCount() { return fFailures.size(); } /** * Returns an Enumeration for the failures */ public synchronized Enumeration<TestFailure> failures() { return Collections.enumeration(fFailures); } /** * Runs a TestCase. */ protected void run(final TestCase test) { startTest(test); Protectable p = new Protectable() { public void protect() throws Throwable { test.runBare(); } }; runProtected(test, p); endTest(test); } /** * Gets the number of run tests. */ public synchronized int runCount() { return fRunTests; } /** * Runs a TestCase. */ public void runProtected(final Test test, Protectable p) { try { p.protect(); } catch (AssertionFailedError e) { addFailure(test, e); } catch (ThreadDeath e) { // don't catch ThreadDeath by accident throw e; } catch (Throwable e) { addError(test, e); } } /** * Checks whether the test run should stop */ public synchronized boolean shouldStop() { return fStop; } /** * Informs the result that a test will be started. */ public void startTest(Test test) { final int count = test.countTestCases(); synchronized (this) { fRunTests += count; } for (TestListener each : cloneListeners()) { each.startTest(test); } } /** * Marks that the test run should stop. */ public synchronized void stop() { fStop = true; } /** * Returns whether the entire test was successful or not. */ public synchronized boolean wasSuccessful() { return failureCount() == 0 && errorCount() == 0; } }

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.3771.767−124.468
Source linesThe number of non-empty source lines.185+74
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.361−6.541

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

Score0.887

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.139+4.071
Number layout frequencyHow rapidly the number of numeric values per line changes through the code.140−2.792
Identifier layout (vertical)How rapidly the visual pattern of identifier characters changes from top to bottom.184.797+2.173
Comment layout (horizontal)How rapidly the visual pattern of comment characters changes from left to right.76.339+0.427
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.77.968+0.363
Operator visual areaThe share of the code’s visual area occupied by operators such as +, =, and *.0.067+0.292

Intercept 0.07 + feature contributions = -0.768 (log-odds).
Score = sigmoid(-0.768) = 0.317.

Score0.635
Score65
Run 1

The code is well-structured with clear separation of concerns, minimal nesting, and concise methods. Naming conventions (f-prefix for fields) and Javadoc comments clarify intent despite the legacy style. Methods are short and actions are generally one per line. The use of cloneListeners() adds slight complexity but improves thread safety. The main readability drawback is the dated Java style, which may feel verbose to modern developers, and the reliance on external classes like TestFailure and Protectable without context. Overall, the code is highly readable for its domain.

Run 2

The code is highly readable and well-structured. It follows a consistent pattern with clear method names and Javadoc comments that explain intent. The class is logically organized with fields grouped at the top and methods grouped by functionality. Nesting is minimal, with only one level of indentation in loops and conditionals. Each line performs a single logical action, making the code easy to follow. The reading flow is natural, moving from setup methods to execution methods to query methods. The use of descriptive variable names like 'each' in for-each loops and 'count' in startTest improves clarity. The only minor issue is the slight repetition in addError/addFailure methods, but this is acceptable for clarity. Overall, this is an excellent example of clean, maintainable code.

Run 3

The code is highly readable. It has a clear, logical class structure with well-separated fields and methods. Nesting is minimal, mostly limited to single-level loops and try/catch blocks. The intent of each method is self-evident from both its name and its Javadoc comment. The code is concise; methods are short and focused on a single responsibility. Action granularity is excellent, with one logical operation per line (e.g., adding a failure, then notifying listeners). The reading flow is natural, moving from setup to individual operations to final checks. Synchronization is applied cleanly to protect critical sections without obscuring the logic.

Run 1

Code Structure: Well organized into small, focused methods for result collection, listener notification, and test execution, though related methods could be grouped more consistently. Nesting: Shallow throughout; the anonymous Protectable implementation adds only modest complexity. Clarity of intent: Descriptive method names and documentation clearly explain behavior, including the failure/error distinction; legacy f-prefixed fields and the parameter p slightly reduce clarity. Code length: Appropriate overall, with some repetitive documentation and listener-notification logic. Action granularity: Statements generally perform one action per line, making state changes and callbacks easy to follow. Reading flow: Consistent formatting and straightforward control flow support easy reading, although mixed synchronization styles and the anonymous class require extra attention.

Run 2

Code Structure: Responsibilities are separated into small, focused methods, though method ordering could better group execution, listener management, and result queries. Nesting: Mostly flat, with shallow loops and exception handling; the anonymous Protectable implementation adds minor nesting. Clarity of intent: Descriptive method names and documentation clearly explain result collection and failure/error distinctions, although f-prefixed fields and names like p and each are less expressive. Code length: Methods are concise; repetitive getter comments and listener-notification patterns add some verbosity. Action granularity: Statements generally perform one action per line, making state changes and notifications easy to follow. Reading flow: Consistent formatting and straightforward control flow support readability, but execution-related methods are scattered, and mixed synchronization styles require additional attention.

Run 3

Code Structure: Small, focused methods cleanly separate result collection, listener notification, execution, and status queries, though related methods are not always grouped together. Nesting: Mostly flat, with shallow loops, synchronization blocks, and exception handling; the anonymous class adds minor complexity. Clarity of intent: Descriptive method names and documentation clearly explain behavior, including the distinction between failures and errors. Legacy f-prefixed fields and abbreviated variables such as p and e slightly reduce clarity. Code length: Appropriately concise overall, although repetitive comments, listener loops, and the two-step listener copy add modest verbosity. Action granularity: Statements generally perform one action per line, making changes and side effects easy to follow. Reading flow: Consistent formatting and straightforward control flow support easy reading; scattered execution-related methods and synchronization details require some extra attention.