On Wed, 18 Dec 2024 14:00:53 GMT, Weijun Wang <wei...@openjdk.org> wrote:
>> `Asserts.assertNotEquals` shows "expected 12345 to not equal 12345" which
>> sounds redundant, just say "expected not equals but was 12345".
>>
>> `Asserts.assertEqualsByteArray` uses the words "expected... to equal...".
>> Modify it to follow the `assertEquals` style ""expected... but was...".
>
> Weijun Wang has updated the pull request incrementally with one additional
> commit since the last revision:
>
> be precise in method spec
test/lib/jdk/test/lib/Asserts.java line 256:
> 254: * @see #assertNotEqualsByteArray(byte[], byte[], String)
> 255: */
> 256: public static void assertNotEqualsByteArray(byte[] unexpected,
> byte[] actual) {
For inequality, would "expectedNot" or "targetValue" better than "unexpected"?
Or is there similar wording used elsewhere that you are basing this on? This
method can be replaced with `!assertEqualsByteArray(...)` and does not seem
that useful to me. If you use "targetValue", this is more neutral name for
arguments. Method name indicates whether the check is for equality or
inequality.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/21101#discussion_r1891087461
