(feat) ListViewMatchers: Add hasPlaceholder(Node placeholder).

[brcolow]

Ideal usage:

FxAssert.verifyThat(lookup("#someListView"), ListViewMatchers.hasPlaceholder(new Label("List is empty!")));

[brcolow]

After doing some exploration/investigate work on this PR, I came up with a general question.

Does adding these types of methods make sense? Basically it is the difference between:

assertThat(listView, ListViewMatchers.hasPlaceholder(new Label("Empty!")));

and

assertThat(listView.getPlaceholder(), LabeledMatchers.hasText("Empty!"));

I am starting to think that the second way is much better (which is counter to the direction of this PR) and would lead to less maintenance over time, as the first method could get unwieldy (as I think you can see it already is started to become with the visible variations). The general strategy going forward would be to have a XMatchers for every X that extends Node in JavaFX.

Tangentially, it would be really nice if there was a way to make assertions more "type-smart" in the sense of e.g. AssertJ, where once can type:

List<String> myList = new ArrayList<>();
assertThat(myList). // <----- invoke completion here

and it shows you type specific assertions based on the type of the object inside the assertThat - such as containsExactly. This would take advantage of modern smart completion that IDEs offer by aiding the user in discovering the different matchers offered by TestFX. Have you thought about this before?

The two concepts that I have talked about are not directly linked together, but I wanted to get my preliminary thoughts/musings out so that you could (hopefully) guide me in the best direction to take as we go forward. In summary, what do you think about the idea behind this PR and the other one?? Are these legitimate additions? Or should we instead only add methods to the XMatchers class (so in this case, since the placeholder property is a Node, it is already covered by NodeMatchers)?

Thanks!

[hastebrot]

Ideal usage:

FxAssert.verifyThat(lookup("#someListView"), 
    ListViewMatchers.hasPlaceholder(new Label("List is empty!")));

For me the "idiomatic way" is:

FxAssert.verifyThat("#someListView", 
    ListViewMatchers.hasPlaceholder("List is empty!"));

I am starting to think that the second way is much better

The second way with listView.getPlaceholder() doesn't work, if you use a string query.

and would lead to less maintenance over time

This is a good point. It would be great, if we find a reliable way to minimize the maintenance of matcher fixtures.

Have you thought about this before?

I thought about types for Iterables a bit. NodeQuery has methods to query a single or multiple Nodes. This allows to use Hamcrest Matchers for Iterables. But there are some issues with Java generics.

In summary, what do you think about the idea behind this PR and the other one?? Are these legitimate additions?

Both PRs improve the cohesion and make the tests more readable, I think.

[hastebrot]

Or should we instead only add methods to the XMatchers class (so in this case, since the placeholder property is a Node, it is already covered by NodeMatchers)?

NodeMatchers contains some convenience methods like hasText(), because they might be used often. Maybe we could place hasPlaceholder() into ControlMatchers? I found getPlaceholder() in ListView, TableView and TreeTableView. TreeView does not have this method.

[brcolow]

For me the "idiomatic way" is:

FxAssert.verifyThat("#someListView",
ListViewMatchers.hasPlaceholder("List is empty!"));

The problem is that this only works for placeholders that are Labeled. Consider, for example, a placeholder that is an ImageView.

Maybe we could place hasPlaceholder() into ControlMatchers
👍

Would you like me to change the PR to to use ControlMatchers?