Databases Reference
In-Depth Information
database solution in a test-driven manner, we provide for the rapid evolution of our
system, and its continued responsiveness to new business needs.
Test-Driven Data Model Development
In discussing data modeling, we've stressed that our graph model should reflect the
kinds of queries we want to run against it. By developing our data model in a test-driven
fashion we document our understanding of our domain, and validate that our queries
behave correctly.
With test-driven data modeling, we write unit tests based on small, representative ex‐
ample graphs drawn from our domain. These example graphs contain just enough data
to communicate a particular feature of the domain; in many cases, they might only
comprise 10 or so nodes, plus the relationships that connect them. We use these exam‐
ples to describe what is normal for the domain, and also what is exceptional. As we
discover anomalies and corner cases in our real data, we write a test that reproduces
what we've discovered.
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 context, we, as the author of the test, know what results to expect.
Tests can act like documentation. By reading the tests, developers gain an understanding
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 is 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, simple, and concise
fashion, than it is to reverse engineer a complex domain from a single 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 domain, others of which exercise it
in the context of some exceptional structure or set of values.
4
Over time, we'll build up a suite of tests that can act as a powerful regression test mech‐
anism. As our application evolves, and we add new sources of data, or change the model
to meet new needs, our regression test suite will continue to assert that existing features
continue to behave as they should. Evolutionary architectures, and the incremental and
iterative software development techniques that support them, depend upon a bedrock
of asserted behavior. The unit-testing approach to data model development described
here enables developers to respond to new business needs with very little risk of un‐
dermining or breaking what has come before, confident in the continued quality of the
solution.
4. Tests not only act as documentation, but they can also be used to generate documentation.
All of the Cypher
documentation in the Neo4j manual
is generated automatically from the unit tests used to develop Cypher.
