Start with the null case, or something that doesn't work
Where to start is often a stumbling point. When you're thinking of the first test to run on a method, pick something simple and trivial. Is there a circumstance in which the method should return null, or an empty collection, or an empty array? Test that case first. Is your method looking up something in a database? Then test what happens if you look for something that isn't there.
Often, these are the simplest tests to write, and they give you a good starting-point from which to launch into more complex interactions. They get you off the mark.
Don't be afraid of doing something trivial to make the test work
So you've followed the advice in point 3, and written the following test:
public void testFindUsersByEmailNoMatch() {
assertEquals(
"nothing returned",
0,
new UserRegistry().findUsersByEmail("[email protected]").length);
}
The obvious, smallest amount of code required to make this test run is:
public User[] findUsersByEmail(String address) {
return new User[0];
}
The natural reaction to writing code like that just to get the test to run is
"But that's cheating!". It's not cheating, because almost always, writing code
that looks for a user and sees he isn't there will be a waste of time - it'll be
a natural extension of the code you write when you actively start looking for
users.
What you're really doing is proving that the test works, by adding the
simple code and changing the test from failure to success. Later, when you write
testFindUsersByEmailOneMatch and
testFindUsersByEmailMultipleMatches, the test will keep an eye on you and
make sure that you don't change your behaviour in the trivial cases - make sure
you don't suddenly start throwing an exception instead, or return null.
Together, points 3 and 4 combine to provide you with a bedrock of tests that
make sure you don't forget the trivial cases when you start dealing with the
non-trivial ones.