It’s very difficult to write a test to ensure that a function NEVER returns null. To do that, I’d have to test every possible scenario and ensure that none of them return null.

But all is not lost…
If we remove the null checks from the calling code and then run a good set of tests on the calling code, then the fact that the calling code does not suffer a NullPointerException is good evidence that the null checks were not needed. In fact, it’s a fairly strong test because we are already testing a case where we might fear that lists or arrays might reasonably be null or empty: We’re testing a class with no class annotations and no methods. We might worry that nulls might occur in an edge case like this. But running the tests, we see that there is no problem.

The method looks like this:
private List processAnnotations(Object o) {
List result = new ArrayList();
[... lots of nasty complex code ...]
return result;
}

So really the question is, “What if someone assigns ‘result=null;’ in the middle of the method?

Well, I looked. There is no such assignment.

And if some later programmer introduces such a bug, then I think that they need to take responsibility for their actions. ;->

And if I’m afraid that someone might accidentally do that, I can discourage them from doing so by adding the word “final”, like this:
private List processAnnotations(Object o) {
final List result = new ArrayList();
[... lots of nasty complex code ...]
return result;
}
Now everyone who looks at the first and last lines of this method will *KNOW* that it never returns null.

On the technical question at hand – the concept of code contracts solves this very issue.