It looks like the hamcrest org.hamcrest.Matchers
class is very similar to org.hamcrest.CoreMatchers
(though it looks like Matchers
has more). Why would I choose to use CoreMatchers
(other than it looks like the class is slightly smaller), and why are these two classes so similar?
The Hamcrest matchers are split into several modules. The "core" includes the most basic matchers and abstract classes required for building other matchers. org.hamcrest.CoreMatchers
includes the factory methods for just these matchers. The other matchers are in the "library" module grouped by the types of objects they match and are optional. org.hamcrest.Matchers
includes both sets of matchers.
Which should you use? I statically import everything from the latter without any trouble. Perhaps the compile times might take slightly longer, but that's never been an issue for me. I put this at the top of my unit tests in addition to the JUnit imports:
import static org.hamcrest.MatcherAssert.*;
import static org.hamcrest.Matchers.*;
This gives the best readability in the test methods.
If you use Mockito a lot (as I do), you might be doing:
import org.mockito.Mockito;
or
static import org.mockito.Mockito.*;
and since the Mockito
class extends Mockito's Matchers
class, then you can end up with conflicts between either the Matchers classes or their static methods. Having CoreMatchers allows me to use JUnit-derived CoreMatchers in the same class as Mockito, without having to full-qualify them at their point of usage.
If you use Android's JUnit tests (not connected tests), the CoreMatcher
s seem to be available inside the already-included junit module, while the Matchers
are not.
Thus, to save overhead, and to avoid importing another library, consider using the CoreMatcher
versions of these classes if they suffice:
assertThat(chrome.twiddle(), is(equalTo(0)));
is possible using only CoreMatcher
s.
© 2022 - 2024 — McMap. All rights reserved.