Add `bytes()`/`bytes(Charset)`/`bytes(String)` navigation methods to `AbstractStringAssert`

[onacit]

Feature summary

Add AbstractStirngAssert#extracting(Charset)AbstractByteArrayAssert so that the byte[] can be verified.

Example

String actual  = "";
assertThat(actual)
        .hasSize(0)
        .extracting(StandardCharset.US_ASCII) // AbstractByteArrayAssert
        .hasSize(0)
;

[scordio]

What if we would stay closer to getBytes(Charset)?

Following the style of other navigation methods, we could add bytes(Charset):

String actual  = "";
assertThat(actual)
        .hasSize(0)
        .bytes(StandardCharset.US_ASCII) // AbstractByteArrayAssert
        .hasSize(0)

I would also consider the variant without parameters and the one with String.

[onacit]

@scordio The bytes(Charset) seems nice. Thank you.

[etrandafir93]

@scordio I was looking into this one as it seems like a good starting point for me to contribute.

I've noticed that there are already methods such as AbstractStringAssert::asByte and AbstractByteArrayAssert::asString and AbstractByteArrayAssert::asString(Charset). What do you think about using the "as" prefix for consistency? so basically asBytes() , asBytes(Charset) and asBytes(String)

Lastly, what do you think the expected behavior should be in case of a null (actual) String? Should It throw an exception right away? or return a ByteArrayAssert with a null actual value? There are a few examples in the PR link

assertThat((String) null).asBytes() // throws error right away?
// or allows
assertThat((String) null).asBytes().isNull() 

[scordio]

Thanks for your interest, @etrandafir93!

I've noticed that there are already methods such as AbstractStringAssert::asByte and AbstractByteArrayAssert::asString and AbstractByteArrayAssert::asString(Charset). What do you think about using the "as" prefix for consistency? so basically asBytes() , asBytes(Charset) and asBytes(String)

To the best of my knowledge, there is no asByte in AbstractStringAssert but we do have other methods like asBase64Decoded.

We tend to favor the as prefix for methods that perform additional transformations under the hood, while we prefer not to use any prefix when we delegate the execution to an API provided by the underlying type. An example is AbstractThrowableAssert::cause that delegates to Throwable::getCause.

For this reason, I would go with bytes for this case.

Lastly, what do you think the expected behavior should be in case of a null (actual) String? Should It throw an exception right away? or return a ByteArrayAssert with a null actual value? There are a few examples in the PR link

It doesn't make much sense to execute navigation methods when the object under test is null, therefore I suggest performing an isNotNull() call internally before creating the new assertion object.

[etrandafir93]

@scordio thanks for the quick feedback! This is the asByte() method i was referring to. I have now applied the suggestions and fixed the formatting issues.

[scordio]

Right, I was mistakenly looking at the released version instead of the latest codebase, sorry 🙂

[etrandafir93]

Hello @scordio, @joel-costigliola,

I've opened the https://github.com/assertj/assertj/pull/3232 some time ago. I'd appreciate your feedback here whenever you have a moment - your time and expertise in reviewing this would mean a lot.

Let me know if there's anything I can do to assist in the process. Thanks, and I'm looking forward to your response.

[scordio]

Hi @etrandafir93 , thanks a lot and apologies for the delay.

We're currently finalizing 3.25.0 and we'll need some time before we can jump on your PR.

As we want to freeze the release scope, I'll schedule your changes for 3.26.0.

[etrandafir93]

@scordio no worries - thanks for reaching out and explaining the process!

[joel-costigliola]

Closed by https://github.com/assertj/assertj/pull/3232