Testing on the Toilet: Truth: a fluent assertion framework
Friday, December 19, 2014
by Dori Reuveni and Kurt Alfred Kluever
This article was adapted from a Google Testing on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office.
As engineers, we spend most of our time reading existing code, rather than writing new code. Therefore, we must make sure we always write clean, readable code. The same goes for our tests; we need a way to clearly express our test assertions.
Truth is an open source, fluent testing framework for Java designed to make your test assertions and failure messages more readable. The fluent API makes reading (and writing) test assertions much more natural, prose-like, and discoverable in your IDE via autocomplete. For example, compare how the following assertion reads with JUnit vs. Truth:
Another benefit of Truth over JUnit is the addition of useful default failure messages. For example:
AssertionError: <[red, green, blue, yellow]> should have contained <orange>
Truth already supports specialized assertions for most of the common JDK types (Objects, primitives, arrays, Strings, Classes, Comparables, Iterables, Collections, Lists, Sets, Maps, etc.), as well as some Guava types (Optionals). Additional support for other popular types is planned as well (Throwables, Iterators, Multimaps, UnsignedIntegers, UnsignedLongs, etc.).
Truth is also user-extensible: you can easily write a Truth subject to make fluent assertions about your own custom types. By creating your own custom subject, both your assertion API and your failure messages can be domain-specific.
Truth's goal is not to replace JUnit assertions, but to improve the readability of complex assertions and their failure messages. JUnit assertions and Truth assertions can (and often do) live side by side in tests.
To get started with Truth, check out http://google.github.io/truth/
This article was adapted from a Google Testing on the Toilet (TotT) episode. You can download a printer-friendly version of this TotT episode and post it in your office.
As engineers, we spend most of our time reading existing code, rather than writing new code. Therefore, we must make sure we always write clean, readable code. The same goes for our tests; we need a way to clearly express our test assertions.
Truth is an open source, fluent testing framework for Java designed to make your test assertions and failure messages more readable. The fluent API makes reading (and writing) test assertions much more natural, prose-like, and discoverable in your IDE via autocomplete. For example, compare how the following assertion reads with JUnit vs. Truth:
assertEquals("March", monthMap.get(3)); // JUnit assertThat(monthMap).containsEntry(3, "March"); // TruthBoth statements are asserting the same thing, but the assertion written with Truth can be easily read from left to right, while the JUnit example requires "mental backtracking".
Another benefit of Truth over JUnit is the addition of useful default failure messages. For example:
ImmutableSet<String> colors = ImmutableSet.of("red", "green", "blue", "yellow"); assertTrue(colors.contains("orange")); // JUnit assertThat(colors).contains("orange"); // TruthIn this example, both assertions will fail, but JUnit will not provide a useful failure message. However, Truth will provide a clear and concise failure message:
AssertionError: <[red, green, blue, yellow]> should have contained <orange>
Truth already supports specialized assertions for most of the common JDK types (Objects, primitives, arrays, Strings, Classes, Comparables, Iterables, Collections, Lists, Sets, Maps, etc.), as well as some Guava types (Optionals). Additional support for other popular types is planned as well (Throwables, Iterators, Multimaps, UnsignedIntegers, UnsignedLongs, etc.).
Truth is also user-extensible: you can easily write a Truth subject to make fluent assertions about your own custom types. By creating your own custom subject, both your assertion API and your failure messages can be domain-specific.
Truth's goal is not to replace JUnit assertions, but to improve the readability of complex assertions and their failure messages. JUnit assertions and Truth assertions can (and often do) live side by side in tests.
To get started with Truth, check out http://google.github.io/truth/
The api seems very similar to AssertJ (https://github.com/joel-costigliola/assertj-core), both of which are a massive improvement over raw JUnit. I've been using AssertJ for probably 8 months and it's fantastic. Does Truth solve some problems that AssertJ does not?
ReplyDeleteHi, I use AssertJ too and I have the same question that Steve.
ReplyDeleteHi!
ReplyDeleteHave you ever try to use rspec ruby gem through jRuby?
In my opinion, rspec has the most advanced testing dsl language.
Regards, Karlo.
Your case would be stronger if contrasted with modern JUnit, that is, `assertThat` + Hamcrest, rather than older constructs such as `assertEquals` or `assertTrue`. Yours is still a better API, but you make a bit of a strawman case against JUnit.
ReplyDeleteExactly this! Also, did you try to work with the JUnit project to get this integrated or this just an other Google NIH project?
Deletelooks like just an other Google NIH project
DeleteArtem, I wrote it and it was inspired by FEST, but I wrote it outside Google, and donated it to Google. I know it's 5 years later, but I feel the need to set the record here, since we evaluated FEST and Hamcrest and AssertJ is a FEST fork. We desired some degrees of extensibility not offered by FEST, and our first preference would have been to use an existing framework. We chose otherwise despite our own self-caution not to merely do NIH.
Deletecan we use this with test automation using selenium webdriver
ReplyDeleteSounds interesting. What advantage does this have over hamcrest?
ReplyDeleteAny recommendation on how to use assertWithMessage? For instance assertWithMEssage("Check orange is present") or assertWithMessage("Orange is missing")
ReplyDelete