Source code
package org.junit.experimental.results;
import org.hamcrest.BaseMatcher;
import org.hamcrest.Description;
import org.hamcrest.Matcher;
import org.hamcrest.TypeSafeMatcher;
/**
* Matchers on a PrintableResult, to enable JUnit self-tests.
* For example:
*
* <pre>
* assertThat(testResult(HasExpectedException.class), isSuccessful());
* </pre>
*/
public class ResultMatchers {
/**
* Matches if the tests are all successful
*/
public static Matcher<PrintableResult> isSuccessful() {
return failureCountIs(0);
}
/**
* Matches if there are {@code count} failures
*/
public static Matcher<PrintableResult> failureCountIs(final int count) {
return new TypeSafeMatcher<PrintableResult>() {
public void describeTo(Description description) {
description.appendText("has " + count + " failures");
}
@Override
public boolean matchesSafely(PrintableResult item) {
return item.failureCount() == count;
}
};
}
/**
* Matches if the result has exactly one failure, and it contains {@code string}
*/
public static Matcher<Object> hasSingleFailureContaining(final String string) {
return new BaseMatcher<Object>() {
public boolean matches(Object item) {
return item.toString().contains(string) && failureCountIs(1).matches(item);
}
public void describeTo(Description description) {
description.appendText("has single failure containing " + string);
}
};
}
/**
* Matches if the result has one or more failures, and at least one of them
* contains {@code string}
*/
public static Matcher<PrintableResult> hasFailureContaining(final String string) {
return new BaseMatcher<PrintableResult>() {
public boolean matches(Object item) {
return item.toString().contains(string);
}
public void describeTo(Description description) {
description.appendText("has failure containing " + string);
}
};
}
}
Run 1
The code is well-structured with clear logical grouping of related matcher factory methods. Documentation is helpful and provides usage examples. Methods are concise and focused with good naming that indicates intent. Nesting is shallow, with anonymous inner classes used appropriately for Hamcrest matchers. One reviewer might argue that anonymous inner classes could be replaced with lambdas for brevity, but the original style maintains clarity. Action granularity is good, and reading flow is natural, making the utility's purpose easily understandable.
Run 2
The code is well-structured with clear purpose and good documentation. Each matcher is concise and follows a consistent pattern. Nesting is minimal - only anonymous inner classes add one level. Action granularity is generally one action per line, though the matches() method in hasSingleFailureContaining combines two operations in one return statement. Reading flow is natural, with methods organized by complexity. Minor issues: some methods could use @Override annotations consistently, and the hasFailureContaining method could be more specific in its matching logic. Overall, the code maintains good readability with clear intent and appropriate length.
Run 3
The code is well-structured and readable. It has a clear class purpose, well-documented matchers, and flat nesting. Each matcher is concise, with single-action methods. The reading flow is natural, moving from simple to complex matchers. Minor readability deductions: anonymous inner classes add structural weight, and `hasFailureContaining` uses `Object` instead of `PrintableResult` in its `matches` method, obscuring type intent. Overall, the code is clear, self-explaining, and easy to follow.
Run 1
Code Structure: Well-organized utility class with small, focused matcher factories and useful documentation. Nesting: Anonymous matcher classes add modest nesting, but there are no deeply nested control structures. Clarity of intent: Descriptive method names and comments make the purpose clear; however, hasFailureContaining checks the result's string representation rather than explicitly checking failures, and hasSingleFailureContaining uses a less-specific Object type. Code length: Concise overall, with some necessary anonymous-class boilerplate. Action granularity: Most lines perform one clear action; the combined condition in hasSingleFailureContaining remains easy to understand. Reading flow: Methods progress naturally from general success and failure-count checks to content checks. Minor inconsistencies in matcher types, method ordering within anonymous classes, and @Override annotations slightly reduce readability.
Run 2
Code Structure: Well-organized matcher factory methods, with useful reuse through failureCountIs. Nesting: Anonymous classes introduce moderate but consistent nesting; there are no deeply nested conditionals. Clarity of intent: Descriptive method names and documentation explain the purpose, although hasFailureContaining checks the entire string representation rather than explicitly checking individual failures, making its documented intent less evident. Code length: Concise overall, with some repetitive anonymous-class boilerplate. Action granularity: Statements generally perform one action per line; the combined condition in hasSingleFailureContaining remains easy to understand. Reading flow: Consistent formatting and self-contained methods support natural reading, though inconsistent matcher types and method ordering within anonymous classes slightly reduce uniformity.
Run 3
Code Structure: Related matcher factories are logically grouped, and isSuccessful reuses failureCountIs. Nesting: Anonymous matcher classes add moderate structural nesting, but method bodies remain flat and simple. Clarity of intent: Descriptive method names and Javadoc clearly communicate purpose; however, hasFailureContaining checks the entire string representation rather than explicitly checking failures, making its documented behavior less apparent. Code length: Compact overall, with some repetitive matcher boilerplate. Action granularity: Statements generally perform one action per line; the combined condition in hasSingleFailureContaining remains easy to understand. Reading flow: Consistent formatting and progression from basic success checks to failure-content checks support natural reading. Generic parameter names such as string and item, plus inconsistent use of @Override, slightly reduce polish.