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!
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.Sign up to join this community
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.
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:
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.