Take the 2-minute tour ×

I am testing a resource management class that is interacting with a database or a file system, or a combination of both. I was wandering if it is the norm to test all possible permutations of read and write for all columns of a data-set when a database is involved. What I mean is:

Database table of test case:

| users                                                                                     |
|       user_id        |      user_name       |      user_email      |      user_role       |
|          1           |      A New Name      | email@provider.com   |          1           |
|          2           |   A different name   | address@domain.com   |          1           |

I could envision something different going wrong in the abstraction layer, updating the first record but no others, updating the second record, but not the fourth, or any of other permutation or combination.

Is it the norm to write tests for all those scenarios (if I am thinking this through correctly it would be 4! = 24 cases, right)?

Now if I want to retrieve columns, I again could imagine something going wrong only retrieving the first and the fourth column, just the third, or all possible permutations of that.

Now what if write and read is mixed, first a read, then a write, then a read. Maybe a write to one column, a read of three columns, then a read of one, or any other permutation. Very soon there are potentially thousands of test cases...

Am I over thinking this and should I just test what I am actually encountering, or is it the norm to do due diligence and test all of this.

I am asking because database access is causing my test suites to balloon in execution time.

Edit: In case this wasn't clear, I am not trying to test if the database is doing what it should be, but if my abstraction layer behaves as intended.

share|improve this question
are you making the database? If you aren't, think about what you're actually testing here. Are you attempting to make sure that your provided database can read and write? Seems like over-doing it to me. –  Ampt Oct 1 '13 at 20:50
I am not making the database, but I am trying to abstract away the database, so I can read/persist data in my project without having to worry where it cam from (a database, a file, the internet...) –  DudeOnRock Oct 1 '13 at 20:52
so you have a connection to a database, and you currently test that connection to make sure it works? Then why do you test each column and row? If the connection works once, I don't think it's too far of a stretch to guess that the rest of the connection tests will work. If you're testing every column in the database for read/write access, I think you took it too far. If you're mocking the database away, why are you testing the mock? –  Ampt Oct 1 '13 at 21:03
Why are you trying to test (reinvent) the wheel? I suggest you read a good book on databases. Pay special attention to Transactions. –  david strachan Oct 1 '13 at 22:30
Maybe this makes clear why you should not try to attempt to add this layer in between? Is it really needed? Isn't there a standard solution in your framework? Or couldn't you make a more specific function which is more obvious in what it does? It feels like yagni but off course it could be a main feature. –  Luc Franken Oct 2 '13 at 9:06
add comment

1 Answer

up vote 1 down vote accepted

I think you are over thinking this. You test for 2 things when unit testing. Does the code do what it is supposed to, and does it handle errors/bad data without crashing.

If you are able to, or did, design the database, then the proper design should handle bad writes assuming you correctly validate your data before writing it. If there is something wrong the database will tell you.

As far as reads go, if the data going into the database was properly validated, you should only get correct data back.

You'll never think of all the possible problem. Make sure your program logs errors that occur. Then evaluate them, and add a new test case if needed.

share|improve this answer
add comment

Your Answer


