Skip to content

Commit

Permalink
Fix JavaDoc warnings and enforce zero errors in Gradle (mockito#2513)
Browse files Browse the repository at this point in the history
Now, we ensure that our JavaDoc doesn't produce any warnings. The most
common problems were using < instead of &lt; and & instead of the word
"and".
  • Loading branch information
TimvdLippe committed Dec 16, 2021
1 parent 8319cc5 commit 80e1cc9
Show file tree
Hide file tree
Showing 21 changed files with 72 additions and 82 deletions.
18 changes: 3 additions & 15 deletions gradle/mockito-core/javadoc.gradle
Expand Up @@ -22,8 +22,6 @@ javadoc {
// While there's errors the javadoc is still generated without those symbols or links ;
// for this reason the javadoc output is suppressed and can be reactivated with --info option.
exclude 'org/mockito/internal'
logging.captureStandardError LogLevel.INFO
logging.captureStandardOutput LogLevel.INFO // suppress "## warnings" message

options.docTitle = """<h1><a href="org/mockito/Mockito.html">Click to see examples</a>. Mockito ${project.version} API.</h1>"""
options.windowTitle = "Mockito ${project.version} API"
Expand All @@ -41,9 +39,7 @@ javadoc {
options.noNavBar = false
options.noTree = false
options.links = ['https://docs.oracle.com/javase/6/docs/api/',
'http://junit.org/junit4/javadoc/4.12/']
options.header("""<em id="mockito-version-header-javadoc7-header"><strong>Mockito ${project.version} API</strong></em>""")
options.footer("""<em id="mockito-version-header-javadoc7-footer"><strong>Mockito ${project.version} API</strong></em>""")
'https://junit.org/junit4/javadoc/4.12/']
options.bottom("""
<script type="text/javascript" src="{@docRoot}/js/jdk6-project-version-insert.min.js"></script>
<script type="text/javascript" src="{@docRoot}/js/jquery-1.7.min.js"></script>
Expand All @@ -53,16 +49,8 @@ javadoc {
<script type="text/javascript" src="{@docRoot}/js/index.js" async defer></script>
""".replaceAll(/\r|\n|[ ]{8}/, ""))
options.stylesheetFile rootProject.file("src/javadoc/stylesheet.css")
options.addStringOption('Xdoclint:none', '-quiet')

def minorVersion = System.getProperty("java.version") =~ /1.8.0_(\d*)/

// Since JDK 8 version 121 scripts are not allowed in comments. However,
// earlier version throw an error if an unknown option is passed.
// Therefore only add this option if the JDK is actually correct.
if (minorVersion.size() > 0 && Integer.valueOf(minorVersion[0][1]) >= 121 || JavaVersion.current().isJava9Compatible()) {
options.addBooleanOption('-allow-script-in-comments', true)
}
options.addStringOption('Xwerror', '-quiet')
options.addBooleanOption('-allow-script-in-comments', true)

doLast {
copy {
Expand Down
2 changes: 1 addition & 1 deletion src/main/java/org/mockito/AdditionalAnswers.java
Expand Up @@ -31,7 +31,7 @@
*
* <p>Currently offer answers that can return the parameter of an invocation at a certain position,
* along with answers that draw on a strongly typed interface to provide a neater way to write custom answers
* that either return a value or are void (see answer interfaces in {@link org.mockito.stubbing}).
* that either return a value or are void (see answer interfaces in org.mockito.stubbing).
*
* <p>See factory methods for more information : {@link #returnsFirstArg}, {@link #returnsSecondArg},
* {@link #returnsLastArg}, {@link #returnsArgAt}, {@link #answer} and {@link #answerVoid}
Expand Down
2 changes: 1 addition & 1 deletion src/main/java/org/mockito/ArgumentCaptor.java
Expand Up @@ -15,7 +15,7 @@
*
* <p>
* Mockito verifies argument values in natural java style: by using an equals() method.
* This is also the recommended way of matching arguments because it makes tests clean & simple.
* This is also the recommended way of matching arguments because it makes tests clean and simple.
* In some situations though, it is helpful to assert on certain arguments after the actual verification.
* For example:
* <pre class="code"><code class="java">
Expand Down
2 changes: 1 addition & 1 deletion src/main/java/org/mockito/ArgumentMatcher.java
Expand Up @@ -80,7 +80,7 @@
* and use a lambda, e.g.:
*
* <pre class="code"><code class="java">
* verify(mock).addAll(<b>argThat(list -> list.size() == 2)</b>);
* verify(mock).addAll(<b>argThat(list -&gt; list.size() == 2)</b>);
* </code></pre>
*
* <p>
Expand Down
10 changes: 5 additions & 5 deletions src/main/java/org/mockito/MockSettings.java
Expand Up @@ -23,12 +23,12 @@
* <p/>
* Don't use it too often.
* Consider writing simple tests that use simple mocks.
* Repeat after me: simple tests push simple, KISSy, readable & maintainable code.
* Repeat after me: simple tests push simple, KISSy, readable and maintainable code.
* If you cannot write a test in a simple way - refactor the code under test.
* <p/>
* Examples of mock settings:
* <pre class="code"><code class="java">
* //Creates mock with different default answer & name
* //Creates mock with different default answer and name
* Foo mock = mock(Foo.class, withSettings()
* .defaultAnswer(RETURNS_SMART_NULLS)
* .name("cool mockie")
Expand All @@ -51,8 +51,8 @@ public interface MockSettings extends Serializable {
* Specifies extra interfaces the mock should implement. Might be useful for legacy code or some corner cases.
* <p>
* This mysterious feature should be used very occasionally.
* The object under test should know exactly its collaborators & dependencies.
* If you happen to use it often than please make sure you are really producing simple, clean & readable code.
* The object under test should know exactly its collaborators and dependencies.
* If you happen to use it often than please make sure you are really producing simple, clean and readable code.
* <p>
* Examples:
* <pre class="code"><code class="java">
Expand Down Expand Up @@ -101,7 +101,7 @@ public interface MockSettings extends Serializable {
* <p>
* However, there are rare cases when partial mocks come handy:
* dealing with code you cannot change easily (3rd party interfaces, interim refactoring of legacy code etc.)
* However, I wouldn't use partial mocks for new, test-driven & well-designed code.
* However, I wouldn't use partial mocks for new, test-driven and well-designed code.
* <p>
* Enough warnings about partial mocks, see an example how spiedInstance() works:
* <pre class="code"><code class="java">
Expand Down

0 comments on commit 80e1cc9

Please sign in to comment.