This article describes how to extend FeathersJS capabilities to handle custom queries in your tests suite based on the specific example of geospatial queries.

Introduction to service mocking

FeathersJS provides a common query syntax, which is a subset of the MongoDB query syntax, on top of its unified service interface out of the box. Any database adapter complies with it and has the same interface as the other adapters. This is really good news because if you’d like to unit test your service you can easily mock it up by using the feathers-memory adapter instead of your actual DB adapter. Indeed, it is usually a better strategy for at least three key reasons:

• it avoids the headache of running a DB in your test setup,
• it is more flexible to generate/check test data using in-memory structures,
• it will run faster.

Using a mocked service is a possible alternative to ease your unit tests (image source https://www.clariontech.com/blog/what-is-mocking-in-php-unit-testing)A snippet of how you can use an in-memory service to mock your DB adapter service in unit tests

Custom queries support

So far, so good. However, each adapter can have this fancy yet powerful feature that you might want to use. For instance, our Weacast solution relies on MongoDB support of query operations on geospatial data. A typical use case is that we store GeoJson polygon features describing the coverage area of some data in the DB and we’d like to retrieve the ones that cover a particular region. For this we issue a query like this:

Geospatial query example on a MongoDB FeathersJS service

Like feathers-reactive, feathers-memory relies on the great sift module to manage the common query syntax on in-memory structures. Indeed, sift works like MongoDB out of the box for the most usual operators. Unfortunately, mocking our geospatial service won’t work out of the box because sift is not aware of any $geoIntersectsoperator by default. Luckily, you’re able to modify the default behavior to suite your needs. Just like standard expressions $not, $eq, and others, you will simply need to add your custom one and replace the default filtering function generated by feathers-memory:

Extending sift capabilities to support geospatial queries

To implement the intersection check between the query region and our in-memory GeoJson structures we use the great turf.js module.

If you liked this article feel free to have a look at our Open Source solutions and enjoy our other articles on Feathers, the Kalisio team !