Building a Graph Database Application - Graph Databases - page 87

return executionEngine . execute ( query , params );
}
// More queries
}
In the constructor for SocialNetworkQueries we create a Cypher ExecutionEngine ,
passing in the supplied database instance. We store the execution engine in a member
variable, which allows it to be reused over and again throughout the lifetime of the
queries instance. The query itself we implement in the distance() method. Here we
create a Cypher statement, initialize a map containing the query parameters, and execute
the statement using the execution engine.
If shouldReturnShortestPathBetweenTwoFriends() passes (it does), we then go on to
test additional scenarios. What happens, for example, if two members of the network
are separated by more than four connections? We write up the scenario and what we
expect the query to do in another test:
@Test
public void shouldReturnNoResultsWhenNoPathUnderAtDistance4OrLess ()
throws Exception
{
// when
ExecutionResult results = queries . distance ( "Ben" , "Arnold" );
// then
assertFalse ( results . iterator (). hasNext () );
}
In this instance, this second test passes without us having to modify the underlying
Cypher query. In many cases, however, a new test will force us to modify a query's
implementation. When that happens, we modify the query to make the new test pass,
and then run all the tests in the fixture. A failing test anywhere in the fixture indicates
we've broken some existing functionality. We continue to modify the query until all tests
are green once again.
Testing server extensions
Server extensions can be developed in a test-driven manner just as easily as embedded
Neo4j. Using the simple server extension described earlier, here's how we test it:
@Test
public void extensionShouldReturnDistance () throws Exception
{
// given
SocialNetworkExtension extension = new SocialNetworkExtension ( db );
// when
String distance = extension . getDistance ( "Ben" , "Mike" );