After about eight years in the making, Google has finally shared the first major release of Truth, a fluent assertion library for Java and Android tests used in the majority of the company’s codebase.
It is meant to make devs’ lives easier by offering faster to type, easier to read test code and by providing clear, helpful failure messages, especially for complex projects. The latter is achieved through the use of a so-called fluent interface, which has the nice side effect of IDEs getting hints on which assertions to suggest if autocompletion is used.
To include Truth in a project, developers will have to do the usual thing of adding the library as a dependency to their build file, and static imports for entry points as well as test assertions into their code.
If you are already familiar with the project, you might be interested to learn that there haven’t been any changes since the last release candidate. However, compared to v0.46, which was the last official release, v1.0 has been fitted with int overloads of isGreaterThan, isLessThan, isAtLeast, and isAtMost, and a couple of changed IntStreamSubject and LongStreamSubject methods amongst other things.
Other than that Optional*Subject.hasValueThat(), AtomicLongMapSubject, DefaultSubject, and the overload of StandardSubjectBuilder.fail(…) that accepts a message, have been removed to make sure their successors are actually used. Since this is v1.0, Guava team member Chris Povirk has made it official that there will be binary compatibility from now on. This and that his team is sorry for taking so long.
Looking forward, there are things like Kotlin-specific enhancements in the works. More information can be found in the project’s repository, where the library can be found under an Apache License 2.0.
If you’re wondering why Google went through all the trouble of creating Truth, when there’s AssertJ (or Hamcrest for that matter) that can do the job, it’s simply because the library goes way back to 2011, when an employee started it as a personal project. Until AssertJ was in a good enough state and the company became aware of it, Truth was already widely used throughout Google and since retrofitting always is an issue, they just stuck with it. Yes, the Truth page says the library wasn’t around when it started, but a quick look into the AssertJ repository would suggest otherwise, so..let’s go with that explanation and question the tool’s name instead.
Google also prefers its own project for its simpler API which tries to provide only one way to perform most tasks and covers the company’s needs with fewer assertions. The latter might not be for everyone however, since this for example means that there’s no support for URI objects or reflective field comparison. But since AssertJ core 3.x isn’t fully Android compliant and Truth works on Android devices by default and allows soft assertions, the choice really is down to project peculiarities and personal preference.