Frankly, I think that convention is far from optimal.
First, the test-prefix is redundant. The annotation already communicates that it is a test method. So why repeat that in the method name?
Second, and more importantly, in my opinion you shouldn't think about it as testing methods at all, you should think about it as testing behavior of the class. Consequently, I like my test method names to communicate the expected behavior.
So names of test methods that I would be likely to use could include
searchOnEmptyCollectionFindsNoResult searchByNameFindsCorrectEntries searchAfterResetFindsFirstHitAgain (or resetClearsCriteria or whatever reset is actually supposed to do)
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
I tend to describe the behavior I'm verifying in the name of my tests, e.g. "fooShouldBarWhenWhizGoesBang()" or "fooTellsAllBarsToCloseTooEarly()".
Sometimes I also do something like this:
That is, I name the test class according to the fixture set up with the @Before method. For example, above we have a cluster of three nodes so I name the test class like that - (Test)ClusterOfThreeNodes. The test methods, on the other hand, read out as statements about the system's behavior in the state described by the fixture (and the class name). For example, "loadBalancesBetweenAllThreeNodesUsingRoundRobin()".
So when I look at a test class, I mentally parse the class and method names as "ClusterOfThreeNodes.loadBalancesBetweenAllThreeNodesUsingRoundRobin".