Because control the contents the test data

our writes require us to read our own write, this technique will significantly impact throughput and latency.

Testing

The example graphs we create for each test comprise the setup or context for that test. Within this context we exercise a query, and assert that the query behaves as expected. Because we control the contents of the test data, we, as the author of the test, know what results to expect.

Tests can act like documentation. By reading the tests, developers gain an under‐standing of the problems and needs the application is intended to address, and the ways in which the authors have gone about addressing them. With this in mind, it’s best to use each test to test just one aspect of our domain. It’s far easier to read lots of small tests, each of which communicates a discrete feature of our data in a clear, sim‐ple, and concise fashion, than it is to reverse engineer a complex domain from a sin‐gle large and unwieldy test. In many cases, we’ll find a particular query being exercised by several tests, some of which demonstrate the happy path through our

First, we create a small graph that is representative of our domain. Using Cypher, we create a network comprising 10 nodes and 8 relationships:

publicGraphDatabaseServicecreateDatabase() {
// Create nodes
StringcreateGraph="CREATE\n"+
"(ben:User {name:'Ben'}),\n"+
"(arnold:User {name:'Arnold'}),\n"+ "(charlie:User {name:'Charlie'}),\n"+ "(gordon:User {name:'Gordon'}),\n"+ "(lucy:User {name:'Lucy'}),\n"+
"(emily:User {name:'Emily'}),\n"+ "(sarah:User {name:'Sarah'}),\n"+ "(kate:User {name:'Kate'}),\n"+
"(mike:User {name:'Mike'}),\n"+
"(paula:User {name:'Paula'}),\n"+ "(ben)-[:FRIEND]->(charlie),\n"+
"(charlie)-[:FRIEND]->(lucy),\n"+ "(lucy)-[:FRIEND]->(sarah),\n"+
"(sarah)-[:FRIEND]->(mike),\n"+
"(arnold)-[:FRIEND]->(gordon),\n"+ "(gordon)-[:FRIEND]->(emily),\n"+ "(emily)-[:FRIEND]->(kate),\n"+
"(kate)-[:FRIEND]->(paula)";