Migrate from JUnit assertions to Truth

[jbduncan]

I'm opening this issue in response to #185 (comment), where the idea came from initially.

[tomnelson]

I would only add to this issue: '...where migrating to Truth improves and clarifies the tests without adding an additional requirement for unit testing of custom Truth Subject instances'.

I fell into that trap when I sought to test maps to Points within a tolerance by using the existing Truth libraries.

If we extend Subject for a lot of our tests, that seems like a 'win'. If it's just for one test, then it's harder to say we improved anything.

Thoughts?

[jbduncan]

Hmm, I'm actually in two minds about this.

Although I did say in #187 (comment) that it's not so clear to me that it's worth for us to write Subject implementations ourselves, I am curious to know if we have any classes in JUNG which we currently write a lot of boilerplate test code for, and if we could potentially abstract out the boilerplate test code for those classes into Subjects for readability. Perhaps such cases would be worth writing extra test code just for the newly-created Subjects?

When we do start migrating to Truth, I suppose we can write custom Subjects if or when we encounter classes with lots of associated boilerplate test code and if we feel like it's worth doing. To me, this seems like an area where having hard and fast rules like "never use Subjects" would limit us a bit too much... 🤔

[tomnelson]

I agree with you. My intent was to say that we should extend Truth when there's a payoff, like use in multiple unit tests. Let's make sure that if we do write extensions to Truth, that we provide sufficient unit testing for those extensions.

…

On Mon, Jan 15, 2018 at 1:17 PM, Jonathan Bluett-Duncan < ***@***.***> wrote: Hmm, I'm actually in two minds about this. Although I did say in #187 (comment) <#187 (comment)> that it's not so clear to me that it's worth for us to write Subject implementations ourselves, I am curious to know if we have any classes in JUNG which we currently write a lot of boilerplate test code for, and if we could potentially abstract out the boilerplate test code for those classes into Subjects for readability. Perhaps such cases would be worth writing extra test code just for the newly-created Subjects? When we do start migrating to Truth, I suppose we can write custom Subjects if or when we encounter classes with lots of associated boilerplate test code and if we feel like it's worth doing. To me, this seems like an area where having hard and fast rules like "never use Subjects" would limit us a bit too much... 🤔 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#188 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAGbB-uEpAS54G8Q6gbzgXt7iT2PcYjIks5tK5YegaJpZM4Rdl-m> .

[wumpz]

Just for couriosity, why do you prefer Truth over AssertJ?

[jbduncan]

@wumpz I can't speak for anyone else, but I prefer Truth to AssertJ for a number of reasons.

I admit a couple of those reasons come from my biases:

1. I learned it first.
2. I'm somewhat biased towards Google Java-based tech in general, including Guava.

But I've also found in my experience, and from reading the Truth devs' comparison of the two libraries, that Truth has two main advantages:

1. Truth's API is smaller, apparently covering all the common cases, so I find it easier to find the right assertion through my IDE's code completion.
2. I find it's a bit more intuitive to understand Truth's assertions from their names than AssertJ's; AssertJ has a number of "puzzlers" such as assertThat(primaryColors).containsAll(RED YELLOW, BLUE), that are described in the comparison above.

The comparison above also explains that AssertJ has advantages over Truth, so if @jrtom wanted us to use AssertJ over Truth, I wouldn't mind. :)

[jrtom]

My biases are basically a stronger version of @jbduncan 's; in my case I'm familiar with Truth but haven't used AssertJ. Plus I know the Truth folks personally in case we have feature requests. :)

I would say that we probably won't need to subclass Subject; not only have we experimented with it here (as @tomnelson said), we've also experimented with doing so for ‘common.graph‘ internally to Google and found that it wasn't adding much value, except possibly at the level of testing graph equality (basically everything else is just Sets).