Configuring unit tests for the adapter:
Add a Makefile:
test:
@./node_modules/.bin/mocha -u tdd --reporter spec
.PHONY: test
In package.json, configure the test script:
"scripts": {
"test": "make test"
}
Running npm test will then run make test, which will invoke mocha to run all the tests under /test.
Unit testing database-driven applications:
Some progress here :)
To implement the queryable interface, understanding the Waterline query language is fundamental.
Basic Solr-Sails test app
I wrote a super simple Sails - Solr integration test to learn some Sails basics and understand the whole workflow from HTTP request to Solr and back.
The adapter here (just a couple of super simple methods are implemented) will grow to become a full sails-solr adapter implementing the queryable interface and at least some of semantinc.
If you don't want to use auto increment integer IDs for your model in Waterline - Sails, you'll need to set the option autoPK to false.
If you want to write a waterline adapter, start by reading the waterline specification of the different interfaces to be implemented.
We'll be using solr-client to build the queries, create "connections" (they're not the same kind of connection you'd have to a SQL db, just HTTP service calls) fetch and parse results.
The queryable waterline interface is implemented in a single method: find.
I'm trying to figure out what's the easiest and more standard way to parse options and turn them into a query. In this case, a Solr query.
The sails-mysql module is useful as an example. I've found it easier to understand than the Mongo or the sails-disk adapter (perhaps since I'm more familiar with MySQL than I am with Mongo).