-
Notifications
You must be signed in to change notification settings - Fork 166
Improve enforcer rule error messages #343
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Changes from all commits
78dd344
d1fa7a2
0a5031a
a2cc5bd
6fed120
f28591c
3a4fc0b
ea184f9
6da5730
1cda31e
4a72198
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -41,12 +41,14 @@ | |
import org.mockito.Mock; | ||
import org.mockito.junit.jupiter.MockitoExtension; | ||
|
||
import static org.junit.jupiter.api.Assertions.assertFalse; | ||
import static org.junit.jupiter.api.Assertions.assertEquals; | ||
import static org.junit.jupiter.api.Assertions.assertNotNull; | ||
import static org.junit.jupiter.api.Assertions.assertNull; | ||
import static org.junit.jupiter.api.Assertions.assertSame; | ||
import static org.junit.jupiter.api.Assertions.assertTrue; | ||
import static org.junit.jupiter.api.Assertions.fail; | ||
import static org.junit.jupiter.api.Assumptions.assumeFalse; | ||
import static org.junit.jupiter.api.Assumptions.assumeTrue; | ||
import static org.mockito.Mockito.when; | ||
|
||
/** | ||
|
@@ -83,18 +85,18 @@ void testFileExists() throws EnforcerRuleException, IOException { | |
} | ||
|
||
@Test | ||
void testEmptyFile() { | ||
void testNullFile() { | ||
rule.setFilesList(Collections.singletonList(null)); | ||
try { | ||
rule.execute(); | ||
fail("Should get exception"); | ||
} catch (EnforcerRuleException e) { | ||
assertNotNull(e.getMessage()); | ||
assertEquals("A null filename was given and allowNulls is false.", e.getMessage()); | ||
} | ||
} | ||
|
||
@Test | ||
void testEmptyFileAllowNull() throws EnforcerRuleException { | ||
void testNullFileAllowNull() throws EnforcerRuleException { | ||
rule.setFilesList(Collections.singletonList(null)); | ||
rule.setAllowNulls(true); | ||
rule.execute(); | ||
|
@@ -124,14 +126,14 @@ void testEmptyFileList() throws EnforcerRuleException, IOException { | |
void testFileDoesNotExist() throws IOException { | ||
File f = File.createTempFile("junit", null, temporaryFolder); | ||
f.delete(); | ||
assertFalse(f.exists()); | ||
assumeFalse(f.exists()); | ||
Comment on lines
-127
to
+129
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It will change test logic ... at all Is it intentional? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, we don't want to test that the JDK's delete method works as expected, and if the code under test isn't even executed then the test has been skipped, not failed. This case inspired me to write https://cafe.elharo.com/testing/assume-vs-assert/ |
||
rule.setFilesList(Collections.singletonList(f)); | ||
|
||
try { | ||
rule.execute(); | ||
fail("Should get exception"); | ||
} catch (EnforcerRuleException e) { | ||
assertNotNull(e.getMessage()); | ||
assertEquals(f.getPath() + " does not exist.", e.getMessage()); | ||
} | ||
} | ||
|
||
|
@@ -144,7 +146,7 @@ void testFileTooSmall() throws IOException { | |
rule.execute(); | ||
fail("Should get exception"); | ||
} catch (EnforcerRuleException e) { | ||
assertNotNull(e.getMessage()); | ||
assertEquals(e.getMessage(), f.getPath() + " size (0) too small. Minimum is 10."); | ||
} | ||
} | ||
|
||
|
@@ -157,12 +159,12 @@ void testFileTooBig() throws IOException { | |
|
||
rule.setFilesList(Collections.singletonList(f)); | ||
rule.setMaxsize(10); | ||
assertTrue(f.length() > 10); | ||
assumeTrue(f.length() > 10); | ||
try { | ||
rule.execute(); | ||
fail("Should get exception"); | ||
} catch (EnforcerRuleException e) { | ||
assertNotNull(e.getMessage()); | ||
assertEquals(f.getPath() + " size (21) too large. Maximum is 10.", e.getMessage()); | ||
} | ||
} | ||
|
||
|
@@ -172,7 +174,7 @@ void testRequireFilesSizeSatisfyAny() throws EnforcerRuleException, IOException | |
try (BufferedWriter out = new BufferedWriter(new FileWriter(f))) { | ||
out.write("123456789101112131415"); | ||
} | ||
assertTrue(f.length() > 10); | ||
assumeTrue(f.length() > 10); | ||
|
||
File g = File.createTempFile("junit", null, temporaryFolder); | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure how it will be worked on windows console ....
Can anybody confirm ...
@michael-o @Bukama
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, this isn't right
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note that this method does not print anything on the console. It throws an exception object that should be identical regardless of the platform that creates it. Where this message goes is outside the scope of this class. It might be written to a log file and never show up on a console. It might be suppressed completely.
In 2025 Windows shells behave in the obvious way if you send them a linefeed, so this works just fine across platforms if someone does happen to print this string to a console. Maybe System.lineSeparator was needed in Windows 95. It isn't now.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
at least jshell handles them the same.
but not cmd
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are you sure about cmd on Windows 10+? I don't have a Windows system handy to test but I asked Gemini and it claims:
The Windows Command Prompt (
cmd.exe
) shell is typically configured to interpret a single Line Feed character (\n
or ASCII 0x0A) as a full line break, even though the native Windows line-ending convention is Carriage Return followed by Line Feed (\r\n
or ASCII 0x0D 0x0A).Therefore, when a Java program sends a string containing only
\n
characters to thecmd
console (viaSystem.out.print
orSystem.err.print
):\n
and translates it for proper display, moving the cursor to the beginning of the next line.The Key Distinction
The behavior depends on where the output is being sent:
\n
Onlycmd.exe
window)\n
and correctly advances the cursor to the start of the next line.> file.txt
)\n
(Unix-style).\r
. Modern editors (VS Code, Notepad++, and newer Windows Notepad) will display it correctly.In summary, when printing directly to the
cmd
window, the Java\n
will result in a clean, new line.