Open fransflippo opened 9 years ago
I don't have my code with me but there was a reason for these names I remember. It has to do with the structure of building the matcher that wraps other matchers so that the HTML would only have to be parsed once. A refactor of names would need to check that use cade as well. If it works there as well I have no objections what so ever.
Also note that the reason that this is a version 0.x is not having to deprecate yet. You can just change since I think FD is currently the only user. When arriving at a nice 1.0 I still think we should donate to jsoup or hamcrest.
I now see you propose "selecting" for the wrapping thingy. If that works then I agree. No emotional attachments to my choices here :)
Only, I vote in favor of keeping hasHref
This is done isn't it?
I see that most operation have been renamed, but the classes themselves still have the old name. Internally we rarely use this artifact any more (as the number of recent changes might suspect) so I'm not sure if all operations are renamed.
Hamcrest matchers are generally named so that an assertThat using the matchers reads like normal English, eg.:
The JsoupMatchers currently don't have this:
I propose to change this. The old versions can be deprecated and removed in the next major version (I guess that would be 1.0). The new names should make sense combined with
assertThat()
and be succinct but sufficiently descriptive, e.g.isElementWithText
orhasText
instead ofwithText
.My proposal:
withName
->hasName
orhasTagName
withText
->hasText
withAttribute
->hasAttribute
withOwnText
->hasOwnText
withData
->hasData
withHtml
->hasInnerHtml
(Jsoup can return both inner and outer HTML)withChildElements
->selecting
(more about this below)withClass
->hasClass
orhasCssClass
containingElementsWithOwnTexts
-> not sure what to do with this one yet. Do we really need it?withHref
-> deprecate it in favor ofhasAttribute("href")
Let me know what you think in a comment.