Add an unwrap method to the API to get actual value

[goatfryed]

Add an unwrap method to the API to get actual value

[scordio]

Could you provide a real-life example you'd like to see improved?

A similar request has been made at #1652 and #3262, but I wonder if yours is 100% a duplicate.

[joel-costigliola]

I want to understand a bit more the problem you are trying to solve @goatfryed.

You are talking about asserting on X and then want to get Y out of X and make further assertions on Y.
I would typically write something like:

// step 1
X x = computeX();
assertThat(x).isNotNull();
Name name = x.getName(); // Y is Name here
assertThat(name).startsWith("Foo");
// step 2
Stuff s = computeStuff(name);
// alternative: call x.getName() twice and remove name local variable
assertThat(s).isNotNull(); 

Is there something that prevents you to do that ? Maybe there is no getName() and you would need to use introspection to get it ? I don't think it is that ugly (but that's just my opinion)

If I understand you correctly, you would prefer code like:

X x = computeX();
Name name = assertThat(computeX()).isNotNull()
                                  .extracting(X::getName) // or extracting("name") by reflection
                                  .startsWith("Foo")
                                  .unwrap();
Stuff s = computeStuff(n); 
assertThat(s).isNotNull(); 

Note this other alternative:

X x = computeX();
Name name = assertThat(computeX()).isNotNull()
                                  .extracting(X::getName) // or extracting("name") by reflection
                                  .startsWith("Foo")
                                  .extracting(n -> computeStuff(n))
                                  .isNotNull(); 

[goatfryed]

I've updated the description. The initial example was indeed quite abstract.

I find this helpful mostly in combination with deeper nested list properties. Especially in combination with thinks like filteredOn.

It's not difficult to access the nested value for further processing, but it feels redundant to traverse the object structure once to assert and then a second time to continue processing.

My use case is mostly in integration test calling various apis. Here, the object tree tends to get large. It's not even mostly about filtering. Some of my use cases include paths like order.items[0].product.relations[0].product.places[0].address. So even if the access chain is straightforward, it feels redundant and makes the test harder to read, because the reader needs to understand that i'm accessing the previously asserted element with my call chain.