Open JakeWharton opened 5 months ago
Once there's an agreement on how to resolve #521, happy to handle this
There is a subtle distinction there, the 'has*' methods do an assertion themselves while the non-has methods can't fail on their own. One thing I'd want to avoid is someone doing assertThat(array).hasSize()
by itself not realizing that it will never fail.
Perhaps "having" could help here, as it seems less like an assertion:
assertThat(list).havingSize()
feels less like a complete sentence.
I also think having
pairs well with extracting
, should we opt not to change it to something like eachHaving
.
I also think
having
pairs well withextracting
, should we opt not to change it to something likeeachHaving
.
Perhaps that's a useful general principle for this kind of thing; a method named with a verb which isn't an assertion should use the continuous ("ing") form of the verb.
That's almost certainly a premature abstraction, and wrong in the details, but I thought it was worth noting down.
Hm, looking at the draft mr I'm not sure I'm convinced that adding a having
prefix to everything is preferable to the status-quo. There are far more methods that the current pattern works for than it doesn't. I think it would still be reasonable to rename toStringFun
and hashCodeFun
to havingToString
and havingHashCode
respectively, but thinking it may be better to keep the rest the same. Thoughts?
What are your primary examples of occurrences you don't like?
From a wider context we are introducing api churn. Which in-itself isn't a bad thing but does mean that there should be a good reason for it.
Let's take message()
for example. We'd go from:
assertThat(exception)
.message()
.isNotNull()
.matches(Regex(...))
to
assertThat(exception)
.havingMessage()
.isNotNull()
.matches(Regex(...))
The first one is shorter and reads slightly better. Like it's not a huge difference but if we are going to change things it should be a more obvious win no?
note: this was partially spurred on by https://github.com/willowtreeapps/assertk/issues/521#issuecomment-2098804966, which also points out than androidx has started using a similar pattern in their [truth extensions](https://developer.android.com/reference/androidx/test/ext/truth/app/NotificationSubject#contentIntent())
I actually think the havingMessage
one reads better, because every function call is in the form of verb-noun, either by itself or in conjunction with the supplied argument.
It produces "assert (that) exception having message is not null matches regex".
It also means that you can type ".having" to see all built-in transformations as well as complete to the lambda variation to do custom transforms.
FWIW, I agree with Jake. I think the consistency of all helper functions starting with "having" helps distinguish them.
The current naming is mostly just the property name as the function name. There's
kClass()
, collectionsize()
s, exceptionmessage()
.This strategy doesn't work for
toString()
orhashCode()
. They get "Fun" suffixes astoStringFun()
andhashCodeFun()
, respectively.This ties in somewhat with #521, and it actually leans me towards that issue choosing "have" so that these could be "has"-prefixed.