Unit Testing

On Friday, we finished creating the first version of the back end API and created unit tests for it. In this testing environment, it was running through our IDEs (WebStorm) and connecting to a MongoDB database running on a server on the LAN sitting on our desks. That server was running Fedora. We used the Mocha JavaScript unit testing frameowork.

We basically had the following pattern: “Send some information in via a POST HTTP request, then use the MongoDB Node.js driver to examine the contents of the database. If what was expected was there, pass, else fail.” An example would be doing a POST request to add a Hit (representing a visitor browsing a page on the site). The Hit model contained the Platform model and Resource model, which held information about the visitor’s web browser, device, which article or other site resource they were viewing, etc.

We had a very liberal view about what information we would accept. Just because the Hit might be missing some fields, perhaps because the visitor’s privacy settings didn’t allow that information to come through, we still want to take it. So we said that unit test would pass if the Hit and its Platform and Resource models were created, and had *any* information.

Other aspects of the tests were more conservative, like the data types. We looked for IP addresses to specifically be strings, for certain ids to be numbers (while most ids were strings) because that’s how Engineering.com stores those ids.

At the end of the day, we were pretty confident we had a working back end that was ready to start logging information.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s