It depends entirely on your general strategy and workflow of using unit tests.
Strict TDD advocates don't care very much precisely what happens when a unit test fails. A NullPointerException is as good as a AccountBalanceViolation to them. Some even advocate writing tests that don't even compile initially, and to treat the compile error as a normal failure that triggers creation of the next bit of business code. All that matters is that the bar is red, and you write code to get it green.
If you are more concerned about readability of test output (perhaps you fear that someone totally else will one day work with the code base, or maybe you are refactoring legacy code that doesn't have any tests), then it can be worthwhile to make sure that if a unit test fails, it will pinpoint the problem as exactly as possible.
In this case, seeing a null reference problem rather than a failed equality is somewhat less clear. But it isn't very much less clear; I don't think it is worth doubling the size of the test. In general, though, it can be.