In the meantime, that can be bypassed by testing the double value directly:

@Test
void testNaN() {
	assertThat(OptionalDouble.of(Double.NaN).getAsDouble()).isNaN();
}

Thanks for reporting it, @Caceresenzo!

@scordio Do you need someone to make a change for this?

Sure, go for it, @pbacz!

@scordio
The simplest solution here would be to replace == comparison with equals() comparison.
This will have a side effect causing any test that compares 0.0 to -0.0 to fail (currently passing).

From the javadoc stating that assertThat(OptionalDouble.of(Double.NaN)).hasValue(Double.NaN) should pass I conclude that this was always the intent to compare using equals().

I propose to replace == check with equals() check and also state clearly in the javadoc which is used.

As this is potentially a breaking change for an edge case I'd like you to confirm if I should proceed with that.

A solution could be to add isNaN() to match AbstractDoubleAssert's API. (and add isNotNaN() too?)

This would prevent breaking changes.

EDIT: typos

@Caceresenzo @scordio
Sure, I can do it either way. All I need is a decision

I think having both isNaN() and isNotNaN() would be best as there do not seems to be a method for the opposite of hasValue(...).

Currently this passes:

assertThat(OptionalDouble.of(Double.NaN))
	.isNotEqualTo(Double.NaN);

(but I am sure its because its testing against the OptionalDouble and not the optional's value itself)

I propose to replace == check with equals() check and also state clearly in the javadoc which is used.

I tend to favor this solution, consistent with what the Javadoc already states and also in line with OptionalDouble::equals.

It's indeed a breaking change and the workaround to get the previous behavior would be something like:

assertThat(OptionalDouble.of(Double.NaN).getAsDouble()).isSameAs(Double.NaN);

@joel-costigliola do you agree?

@scordio @joel-costigliola
I created a PR for this issue.

Integrated thanks @pbacz !