Tonight, I was plodding through the process of getting to know MongoDB and its java driver, TDD style. This is an interesting experience, as most of one’s development is going to involve technologies with which one is familiar and working out designs. This is classic problem isolation — all of your tools are familiar, and you have only to work out the design itself. In this case, I have two problems – the technology and the design aren’t familiar. In situations like this, it’s even more important to follow your nose when it comes to smells in code or tests, as you’re really flailing around in the dark. These may be the only things that guide a technology initiate to good practice short of taking a class or reading some books (and even then, they’re important, because you can only learn so much without getting your hands dirty.
Last time in this series, I posted about a good reminder of a couple of principles of good object oriented design (respecting the Law of Demeter and avoiding static method invocations as much as possible). Today, I’m going to double back on this consciously a bit to explore some more possibilities in JUnit. Don’t worry – I will fix the design in subsequent posts.
Today, I’d like to accomplish the following:
- Have a mock change with each invocation
- Mock a low of demeter violation in as little code as possible
To the Code!
If you’ve followed my last few posts, you’ve noticed that I setup MongoDB. So, logically, the next step is connecting to it with my application, and the next step after that is mocking this connection so that I can unit test the logic (well, since I’m following TDD, technically the mocking comes first). Through trial and error in a throw-away piece of code, I discovered that I could access my database as so:
In my last post, I covered installing MongoDB on Fedora. This is another post as much for my reference as for anything else, and I’ll go over here getting set up so that my application successfully uses the MongoDB server.
When I left off last time, I had successfully configured the server to allow me to create documents using the mongo command line utility. So, I created a collection and a document and was ready to access it from my web application. Following the examples in the MongoDB java tutorial, I created the following implementation of my HouseService interface that I had previously hard coded room values into:
This is one of those posts as much for my own reference as anything else, and if it helps others, then bonus.
I installed MongoDB on my old Fedora server just now, and while it was actually pretty straightforward to do, I figured I’d document the steps. The first thing to remember is that there are two separate installs: the client and the server (this is what tripped me up on the MongoDB site’s documentation). There isn’t some deal where running server install also gives you a client.
So, to set up a smooth, easy install with yum, the first thing you need to do is create the file “/etc/yum.repos.d/10gen.repo”. Once you’ve created that file, open it and add the following:
Now, once you’ve got that in place, run the command, “yum install mongo-10gen mongo-10gen-server”. This will install both the client and the server. When the client and the server are in place, you can start the server by running “/etc/init.d/mongod start”. Finally, if you’re like me, you probably want the server to run automatically. If that’s the case, execute the command “chkconfig mongod on”.
And, you’re set. MongoDB server is installed and running and will also run on your next reboot.