I'm working in TDD for my data access layer in MongoDB and I don't know what should I test?

I think that I shouldn't test if the queries return what they have to return because It's a MongoDB concern.

Some help please!

  • 2
    Do you have application logic in the database layer? If so, that's what you test. If not, why are you testing the database? Usually you just test the code that calls the database. – Berin Loritsch Feb 20 at 4:31
  • AS @BerinLoritsch commented. Look at your code. Look at the classes, functions, attributes, etc. Look at your control structures (loops, if, try/catch), look at your error handling. Basically, look at the code you wrote, that's what you have to test. Then look at the external dependencies such as the DB, file system, etc and replace them with stubs/mocks/dummies, whatever it works for you. – Laiv Feb 20 at 13:16

That is precisely what you should be testing - The magic line that accepts data from your application and persists it somewhere, later to return it to your application.

They just are not called Unit Tests.

The Difference

Unit tests are fast, they should each execute in the 10ms (0.01s) or less. Calculate that out:

               tests per total time
time (secs)  | 1 000   | 2 000   | 10 000     | 50 000 
0.001        | 1s      | 2s      | 10s        | 50s
0.01         | 10s     | 20s     | 1m 40s     | 8m 20s
0.1          | 1m 40s  | 3m 20s  | 16m 40s    | 1h 23m 20s
1            | 16m 40s | 33m 20s | 2h 46m 40s | 13h 53m 20s

The faster the tests are the more you can have and still keep that positive feedback loop tight. The problem with database testing is that they are slllloooooooowwwwww. This is what makes them not unit tests.

How to Test

However it is still important to verify that the system behaves as expected, which does include verifying that persistence layer. Obviously the database engine has gone through a lot of testing already, so you can be pretty confident that indecies, tables, documents, json, etc are roughly correct. What you need to test is how that system has been configured and extended by you for your application.

This is what you might call the data access layer. Below this layer exists all of the custom code that handles the serialisation logic, connection management, db driver, etc... along with the custom data structures and logic that has been added to the database itself.

If you can, you want to pull as much of that logic into modules that can be unit tested. This pay dividends as they are faster, giving that tight feed back loop, and additionally permit simpler tests for verifying the mechanisms.

This should leave two places needing testing:

  • A thin logic wrapper around the db driver
  • the database structure, configuration, and stored logics.

Hopefully the logic layer around the database driver is thin enough that a few simple tests give a decent chance of detecting issues. Additionally these drivers do not tend to change often so infrequent testing may be a tenable position. Fortunately Mongo also offers a number of mock db drivers that can be dropped in. If you can, take advantage of these to test the remainder of your custom logic quickly.

That just leaves the database structures themselves. At the very least you should verify permissions: can the application exercise the required operations, are the correct structures available, can the application perform actions/see data it should not?

You should also exercise any custom stored logic inside the database. Does it retrieve/update the data as expected? Does it fail in an expected way under certain circumstances?

Rule of Thumb

The best rule of thumb I've every heard is that:

The Tests are a description of the system. If tomorrow we deleted the entire source of the application/db, could you rewrite the system by simply making the tests pass?

Whenever I get stuck trying to figure out what to test that is what I consider.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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