Testing

Groovy Spock

We're big believers in testing our code, both for correctness, as well as to ensure that changes don't unintentionally break existing contracts unintentionally. For example, we rely heavily on the Spock framework for our backend service tests, and see a lot of benefit from it's conciseness, built-in mocking framework, and the fact that it uses Groovy.

We also strive for very high-quality code, with the belief that quality code is easier to maintain, easier to understand, and has fewer bugs. To help keep the quality bar high. For instance we have an automated style checker (Checkstyle) in our Maven-based projects with rules that should catch most of the common style issues.

Database

Database-related tests contain 2 parts

1. Groovy Spock unit tests on

   • Injected Query DataFetcher
   • Injected Mutation DataFetcher

2. Live DB tests on endpoints

   • In file servlet endpoint test and meta data servlet endpoint test, Flyway migration injects real data into a Derby in-meomroy SQL DB
   • The Derby data is injected via a shared DBCP DataSource declared in application BinderFactory
   • The application resource is set alive through JettyServerFactory

Reference - Apache Commons DBCP2

For testing Book example application, we use Derby's in-memory database facility, which resides completely in main memory, not in the file system.

In addition, we use Apache DBCP 2 to provide DataSource pointing at the in-memory Derby instance.

Derby

Derby was meant to be used only in tests and, hence, must be imported in test scope only