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.