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 protected] | 1 |
+----------------------+----------------------+----------------------+----------------------+
| 2 | A different name | [email protected] | 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.
5
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.