Test code should be very defensive.
After all, we're running test code because we want to make sure that an external system (the system under test) does what we expect. If we knew beyond the shadow of a doubt that it worked, then we wouldn't bother running the test. So, we're only running the test because we don't know with 100% confidence that it will work. And that's when we have to be defensive in our coding. We're already looking for things "that should never happen", so let's write our test programs so they can handle them.
Make sure you at least consider whether you might need:
- Asynchrony and/or timeouts. Does the system not returning mean your test will hang?
- Null checks. "That should never be null" is a lot easier to trace if you check when you first see it rather than waiting for it to blow up somewhere later in your code.
- Try/catches. "The program should never throw an exception", key word "should"
- Results inspection. Just because the program returned something and didn't error doesn't mean that return matches what you thought.
Basically, your goal is to either produce a "pass" or a legible failure. Keep in mind that automated tests ted to (1) have a long life; and (2) be run mostly by people or systems other than the ones who wrote them. Just because you the test author knows what it means, that doesn't mean it'll be obvious to the QA engineer evaluating the output of the results a year from now (even if that QA engineer IS the test author!).
Keep your tests defensive, keep your error messages useful, and let your tests have a good long life.