In the first part of this blog series, we covered the basic mechanics of our application and undertook some data modeling. In this second part, we will create tests that validate the behavior of our application and then describe how to set-up and run the application.
Write the tests first
Let’s begin by defining some small configuration libraries.
file name: test/config/test_config.js
Our server will be running on port 8000 on localhost. This will be fine for initial testing purposes. Later, if we change the location or port number for a production system, it would be very easy to just edit this file.
To prepare for our test cases, we need to ensure that we have a good test environment. The following code achieves this for us. First, we connect to the database.
file name: test/setup_tests.js
Next, we drop the user collection. This ensures that our database is in a known starting state.
Next, we will drop the user feed entry collection.
Next, we will connect to Stormpath and delete all the users in our test application.
Next, we close the database.
Finally, we call async.series to ensure that all the functions run in the correct order.
Frisby was briefly mentioned earlier. We will use this to define our test cases, as follows.
file name: test/create_accounts_error_spec.js
We will start with the enroll route in the following code. In this case we are deliberately missing the first name field, so we expect a status reply of 400 with a JSON error that we forgot to define the first name. Let’s “toss that frisby”:
In the following example, we are testing a password that does not have any lower-case letters. This would actually result in an error being returned by Stormpath, and we would expect a status reply of 400.
In the following example, we are testing an invalid email address. So, we can see that there is no @ sign and no domain name in the email address we are passing, and we would expect a status reply of 400.
Now, let’s look at some examples of test cases that should work. Let’s start by defining 3 users.
file name: test/create_accounts_spec.js
In the following example, we are sending the array of the 3 users we defined above and are expecting a success status of 201. The JSON document returned would show the user object created, so we can verify that what was created matched our test data.
Next, we will test for a duplicate user. In the following example, we will try to create a user where the email address already exists.
One important issue is that we don’t know what API key will be returned by Stormpath a priori. So, we need to create a file dynamically that looks like the following. We can then use this file to define test cases that require us to authenticate a user.
file name: /tmp/readerTestCreds.js
In order to create the temporary file above, we need to connect to MongoDB and retrieve user information. This is achieved by the following code.
file name: tests/writeCreds.js
In the following code, we can see that the first line uses the temporary file that we created with the user information. We have also defined several feeds, such as Dilbert and the Eater Blog.
file name: tests/feed_spec.js
Previously, we defined some users but none of them had subscribed to any feeds. In the following code we test feed subscription. Note that authentication is required now and this is achieved using .auth with the Stormpath API keys. Our first test is to check for an empty feed list.
In our next test case, we will subscribe our first test user to the Dilbert feed.
In our next test case, we will try to subscribe our first test user to a feed that they are already subscribed-to.
Next, we will subscribe our test user to a new feed. The result returned should confirm that the user is subscribed now to 2 feeds.
Next, we will use our second test user to subscribe to a feed.
The REST API
Before we begin writing our REST API code, we need to define some utility libraries. First, we need to define how our application will connect to the database. Putting this information into a file gives us the flexibility to add different database URLs for development or production systems.
file name: config/db.js
If we wanted to turn on database authentication we could put that information in a file, as shown below. This file should not be checked into source code control for obvious reasons.
file name: config/security.js
We can keep Stormpath API and Secret keys in a properties file, as follows, and need to carefully manage this file as well.
file name: config/stormpath_apikey.properties
Express.js overview
In Express.js, we create an “application” (app). This application listens on a particular port for HTTP requests to come in. When requests come in, they pass through a middleware chain. Each link in the middleware chain is given a req (request) object and a res (results) object to store the results. Each link can choose to do work, or pass it to the next link. We add new middleware via app.use(). The main middleware is called our “router”, which looks at the URL and routes each different URL/verb combination to a specific handler function.
Creating our application
Now we can finally see our application code, which is quite small since we can embed handlers for various routes into separate files.
file name: server.js
We define our own middleware at the end of the chain to handle bad URLs.
Now our server application is listening on port 8000.
Let’s print a message on the console to the user.
Defining our Mongoose data models
We use Mongoose to map objects on the Node.js side to documents inside MongoDB. Recall that earlier, we defined 4 collections:
- Feed collection.
- Feed entry collection.
- User collection.
- User feed-entry-mapping collection.
So we will now define schemas for these 4 collections. Let’s begin with the user schema. Notice that we can also format the data, such as converting strings to lowercase, and remove leading or trailing whitespace using trim.
file name: app/routes.js
In the following code, we can also tell Mongoose what indexes need to exist. Mongoose will also ensure that these indexes are created if they do not already exist in our MongoDB database. The unique constraint ensures that duplicates are not allowed. The “email : 1” maintains email addresses in ascending order. If we used “email : -1” it would be in descending order.
We repeat the process for the other 3 collections.
The following is an example of a compound index on 4 fields. Each index is maintained in ascending order.
Every route that comes in for GET, POST, PUT and DELETE needs to have the correct content type, which is application/json. Then the next link in the chain is called.
Now we need to define handlers for each combination of URL/verb. The link to the complete code is available in the resources section and we just show a few examples below. Note the ease with which we can use Stormpath. Furthermore, notice that we have defined /api/v1.0, so the client would actually call /api/v1.0/user/enroll, for example. In the future, if we changed the API, say to 2.0, we could use /api/v2.0. This would have its own router and code, so clients using the v1.0 API would still continue to work.
Starting the server and running tests
Finally, here is a summary of the steps we need to follow to start the server and run the tests.
- Ensure that the MongoDB instance is running
- mongod
- Install the Node libraries
- npm install
- Start the REST API server
- node server.js
- Run test cases
- node setup_tests.js
- jasmine-node create_accounts_error_spec.js
- jasmine-node create_accounts_spec.js
- node write_creds.js
- jasmine-node feed_spec.js
MongoDB University provides excellent free training. There is a course specifically aimed at Node.js developers and the link can be found in the resources section below. The resources section also contains links to good MongoDB data modeling resources.
Resources
Chad Tindel’s Github Repository
M101JS: MongoDB for Node.js Developers
Data Modeling Considerations for MongoDB Applications
Interested in learning more about how to build node.js apps with MongoDB? Register for our upcoming webinar here:
About the Author - Norberto
Norberto Leite is Technical Evangelist at MongoDB. Norberto has been working for the last 5 years on large scalable and distributable application environments, both as advisor and engineer. Prior to MongoDB Norberto served as a Big Data Engineer at Telefonica.