FAQ entry: Why we don't support multiple chained calls to assertion methods on the same Subject

[timurt]

Hi

I have the following assertions:

        String str = ...;
        assertWithMessage(errorMessage)
                .that(str)
                .startsWith("some prefix");
        assertWithMessage(errorMessage)
                .that(str)
                .contains("some content");
        assertWithMessage(errorMessage)
                .that(str)
                .endsWith("some suffix");

As you can see I make several assertions over one str object It would be easier to understand if all assertions were combined together like:

        assertWithMessage(errorMessage)
                .that(str)
                .startsWith("some prefix")
                .contains("some content")
                .endsWith("some suffix");

I know there are several ways how to overcome it (assign assertWithMessage(errorMessage).that(str) to variable and call assertions for it or by using regular expressions), but sequential invocation of assert methods over one object seems more natural to me

---

Please guide me, if such functionality already exists

[cpovirk]

We don't provide an easier way to do this. We should write about why in the FAQ.

Most of the reason is that we were concerned about confusion between this sort of "chaining" and the sort of "chaining" that we provide with assertions like assertThat(exception).hasCauseThat().isInstanceOf(FooException.class). For example:

assertThat(someList)
    .containsExactly(a, b)
    .inOrder();

Is that an assertion that the list contains a and b, with a appearing before b? Or is it an assertion that the list contains a and b and that the entire list (which may contain more elements) is in lexicographical order? (I grant the actual answer is relatively obvious in this case, so I should come up with a better example :))

Another contributing factor is that this approach is only reliably possible if most Subject subclasses declare a "self type" type parameter. We found that people who wrote Truth extensions rarely did this, so chaining did not work in some cases. And in the cases in which people did declare self-type type parameters, they needed additional abstract classes with type parameters (and sometimes that's in combination with more type paramters) to make all the generics work out right.

Previously: https://github.com/google/truth/issues/253 https://github.com/google/truth/pull/37 https://github.com/google/truth/pull/6

(Kotlin provides a syntax that makes this work better, and we may try to make it work still better there: https://github.com/google/truth/issues/572)

I'm going to re-purpose this issue to about about adding a FAQ entry.

[cpovirk]

(That FAQ entry can also mention the specific approach you discuss in the PR you cross-linked -- using regex instead of startsWith+contains+endsWith. We might have other advice to give, too, like not necessarily worrying about calling isNotNull() before dereferencing a possibly null object.)

[kevinb9n]

I expect everyone to want this at one time or another.

But our equation is basically: a moderate API convenience isn't worth even the smallest risk of user confusion (especially user confusion that can lead to false-negative assertions!).

(If we mention the regex workaround we should note that that switch could easily be a step backward in error message usefulness.)