Feature summary

I propose the additional of a unwrap method to get the actual value of the current Assert

Example

String objName = assertThat(obj).extracting(MyClass::getName).isNotNull().unwrap()

Reasoning

Ideally, in unit tests and with assertJ's fluent api, there should be little need to get the actual value back.
The use of some unwrap method might indicate bad test design, because a test should do only one thing and if you need a nested value for anything other than more assertions, your test does more than one one thing probably.

I assume this is part of the reason why it doesn't exist at the moment. No need/could promote bad practice.

Lately, I've used assertJ a lot for system integration tests on rest api level as well together with other great libraries like awaitility. I often find myself in the situation that I need to verify nested objects and then continue with them.

Compare this case

var order = orderApi.getOrder(orderId);
var troubleTicketRef = assertThat(order)
    /* ... order assertions */
    .extracting(Order::getPositions)
    .asInstanceOf(list(Position.class))
    .singleElement()
        /* ... position assertions */
        .extracting(Position::getReferences)
        .asInstanceOf(list(Reference.class))
        .filteredOn("type", "troubleTicket")
        .singleElement()
            /* ... assertions on config reference **/
            .unwrap();

var troubleTicket = troubleTicketApi.get(troubleTicketRef.getId());
assertThat(troubleTicket)
    /* ... */;

At that point I find myself to replicate a lot of the access or assertion logic, because I can't just simply get Y out of the assertion chain.

A workaround is to use satisfy to save the actual value in a reference and retrieve it by side effect, but that is ugly of course.

So for use cases on a higher level than unit tests, I think an unwrap method would be a great addition.

Sorry, if this was asked before. I searched through the repository to find something similar. I would have made a simple PR and let you decide there for this minor addition, but I wanted to understand and respect the project philosophy before I do that.