Platform (JVM and/or JS): JVM (only jdk8)
expect(Optional.of(1)).isPresent().toBe(1) // isPresent incorporates check for empty
//instead of
expect(Optional.of(1)).feature(Optional::get).toBe(1) // get throws in case of empty
//and
expect(Optional.of(1)).isPresent { // isPresent incorporates check for empty
isGreaterThan(1)
isLessThan(4)
}
//instead of
expect(Optional.of(1)).feature(Optional::get) { // get throws in case of empty
isGreaterThan(1)
isLessThan(4)
}
In reporting we want to see for
expect(Optional.empty<Int>).isPresent().toBe(1)
the following report:
expect: Optional.empty
◆ ▶ get(): ❗❗is empty
and for
expect(Optional.empty<Int>).isPresent() { toBe(1) }
the following
expect: Optional.empty
◆ ▶ get(): ❗❗is empty
>> to be: 1
and for
expect(Optional.of(2)).isPresent() { toBe(1) }
the following:
expect: Optional[2]
◆ ▶ get(): 2
◾ to be: 1
Following the things you need to do:
lib
domain
ExtractedFeaturePostStep<T, E> where T: Optional<E> (see ResultAssertions.isSucces as a guideline)api
Expect<E> (see resultAssertions.kt as a guideline) and add @since 0.9.0 to the KDOCExpect<T> (see resultAssertions.kt as a guideline) and @since 0.9.0 (adopt to current version) to the KDOCI'll work on this if you would like to take this issue over.Suggestion: if get would be called toBePresent (without any other change), it would be more obvious that it actually contains an assertion.
I try to use the same names one is already familiar with for feature extraction, IMO this way we have a more intuitive API than inventing new names. We already have List.get, Throwable.message let's stick with that pattern. We could introduce isPresent in addition though.
I mulled your input over and I came to the conclusion that get might indeed not be the best choice for the naming. I think isPresent is better as it is an obvious counterpart to isEmpty and many people argue that it is discouraged to use Optional.get (because it throws if empty). Thus I guess those people would look for an isPresent or getOrElse but getOrElse does not make sense in this context.
I'll work on this
I think isPresent is better than get. And I think you give good reasons!
@byarr I have updated the description regarding reporting.
@byarr do you need help?
@robstoll Sorry, I did take quick look at this. But I havnt really got the time right now. Unassigning myself.
@byarr no problem if you need longer, just wanted to make sure you are not stuck. Rich out here if you want to take it over again and I re-assign it to you.
I'll work on this.
In the description, you mention "ExtractedFeatureOption" but I don't find this class. I assumed it was ExtractedFeaturePostStep when I looked at the examples provided. Am I right or I am missing something?
That's correct. The class was renamed since I created this issue
implemented with 8cd76f3