Databases Reference
In-Depth Information
// Populate graph
}
Here we're using an instance of
CommunityNeoServer
to host the extension. We create
the server and populate its database in the test fixture's
init()
method using a
Server
Builder
, which is a helper class from Neo4j's server test jar. This builder enables us to
register the extension package, and associate it with a relative URI space (in this case,
everything below
/socnet
). Once
init()
has completed, we have a server instance up
and running and listening on port 7474.
In the test itself,
serverShouldReturnDistance()
, we access this server using an HTTP
client from the
Jersey client library
.
The client issues an HTTP GET request for the
resource at
http://localhost:7474/socnet/distance/Ben/Mike
. (At the server end, this re‐
quest is dispatched to an instance of
SocialNetworkExtension
.) When the client re‐
ceives a response, the test asserts that the HTTP status code, content-type, and content
of the response body are correct.
Performance Testing
The test-driven approach that we've described so far communicates context and domain
understanding, and tests for correctness. It does not, however, test for performance.
What works fast against a small, 20-node sample graph may not work so well when
confronted with a much larger graph. Therefore, to accompany our unit tests, we should
consider writing a suite of query performance tests. On top of that, we should also invest
in some thorough application performance testing early in our application's develop‐
ment life cycle.
Query performance tests
Query performance tests are not the same as full-blown application performance tests.
All we're interested in at this stage is whether a particular query performs well when
run against a graph that is proportionate to the kind of graph we expect to encounter
in production. Ideally, these tests are developed side-by-side with our unit tests. There's
nothing worse than investing a lot of time in perfecting a query, only to discover it is
not fit for production-sized data.
When creating query performance tests, bear in mind the following guidelines:
• Create a suite of performance tests that exercise the queries developed through our
unit testing. Record the performance figures so that we can see the relative effects
of tweaking a query, modifying the heap size, or upgrading from one version of a
graph database to another.
