In my previous article, MongoDB’s basics took front and center: getting it installed, running and inserting and finding data. However, I covered only the basics—the data objects used were simple name/value pairs. That made sense, because MongoDB’s “sweet spot” includes unstructured and relatively simple data structures. But surely this database can store more than just simple name/value pairs.
In this article, we’ll use a slightly different method to investigate MongoDB (or any technology). The procedure, called an exploration test, will help us find a possible bug in the server and, along the way, highlight one of the common issues object-oriented developers will run into when using MongoDB.
In Our Last Episode …
First we’ll make sure we’re all on the same page, and we’ll also cover some slightly new ground. Let’s look at MongoDB in a bit more structured fashion than we did in the previous article (msdn.microsoft.com/magazine/ee310029). Rather than just create a simple application and hack on it, let’s kill two birds with one stone and create exploration tests—code segments that look like unit tests but that explore functionality rather than try to verify it.