Let me give a little bit of background for this question. For the record, this is a question about architecture and software engineering practice and not about the specific technologies that I am using. So any DB+container experience/thoughts are welcome!

Key Points:

  1. I am developing a library that comprehensively uses Mongo DB.
  2. I would like to develop unit tests for said library.
  3. I am currently testing against a real mongo instance on a physical server.
  4. I have searched high and low for good mock mongo DBs that I could use for unit testing and for some reason or another they didn't meet all of my needs.
  5. In addition to software problems, I have had a litany of hardware-related problems (while running the unit tests) with maintaining my own Linux server running Mongo.

So here is my question... why not just spin up a Docker container with MongoDB on it? I can spin it up during the unit tests, test against the real mccoy and then shut it down...

I'd like for the answer (if possible) to hit some of these points (if applicable):

  1. Managing Dependencies
  2. CI/CD
  3. Version Control
  • You seem to asking if this is a "bad idea." I don't see any particular downsides, other than it sounds like you want to just spin up a copy of the production database in its own container for testing purposes, a maneuver that would probably violate Sarbanes Oxley and/or HIPAA laws (if those are applicable). – Robert Harvey Apr 21 at 22:54
  • @RobertHarvey not just if it's a bad idea, I want some specific points, especially applicable to those i've outlined. No socks is not a concern for me here. – Snoop Apr 21 at 22:55
  • also doesn't need to be those specific points... but whatever people may think of. – Snoop Apr 21 at 22:56
  • Do you have any particular reason to believe their might be some issues? Normally, the way you see how well this works is to spin up a Docker container and see how well this plays in your own sandbox. We're not clairvoyant; we have no idea what issues you might encounter in your specific environment. Standing up a Docker container is a pretty straightforward affair. – Robert Harvey Apr 21 at 22:57
  • As to your points, the whole point of Docker containers is to better manage dependencies, CI/CD and Version Control, so. – Robert Harvey Apr 21 at 22:58

why not just spin up a Docker container with MongoDB on it?

Because, by definition, you’re not testing a single isolated unit of work if it needs Mongo to work.

In practice, it’s difficult to run your unit tests in isolation on the shared DB, which limits your parallelization options. Adding/removing data from the DB tends to be fragile compared to mocking. And of course, it’s a bandaid for actually decoupling mongo from your app and all the benefits therein.

  • 2
    Well, yeah... It's not unit testing, for sure. – Robert Harvey Apr 21 at 22:59
  • agreed, guess i should say more integration testing – Snoop Apr 21 at 23:02
  • but no, i was really thinking of it for my unit tests, call it what you may – Snoop Apr 21 at 23:02
  • i actually did try to write my own mock, and it works well, but i haven't expanded it too much and thus am still using the physical for some stuff, since its a lot of work to maintain... problem is with a lot of the mongo mock DBs is that they dont support parallel processing – Snoop Apr 21 at 23:03
  • so i am doing stuff like locks and concurrency to do the mock, i just want to focus on the application – Snoop Apr 21 at 23:04

Not the answer you're looking for? Browse other questions tagged or ask your own question.