Regarding your particuliar example, you should in fact consider to do 2 tests for it:
- The first one is a Unit Test, and will check that your function can accept the maximum number of input requested by the requirements. If nothing is specified there, ask for clarification to the analyst. Dynamically generated requests such as this are a pain to debug afterward.
- The second one is a Stress test. But it should not be performed onthis particular part of your code, but rather on the integrated part tha will use it. If you start stress testing unit block, you'll end up doing premature optimisation because you'll loose the big picture and start making assumptions on how this will work togetheter rather than observing how it does really.
manpreet![Tuteehub forum best answer]()
Best Answer
2 years ago
I am wondering if you guys have any good reading to consider what to classify as unit testing / acceptance / integration testing. I have the following scenario and we're having a bit of a debate at work if it should be in unit tests:
In our data access layer, some statements use sql such as "select * from people where id IN ('x', 'y'), where the IN statement is dynamically generated according to the input. Recently we found out that our Oracle db have a limit of 1000 variables within the IN statement.
I personally think this is not a unit testing scenario. We test if the sql work against the database in unit tests and if the logic is right. However, stress testing should be done at higher level.
If we are to do testing with 1000s of records in unit tests, we need to fill the database each time with large number of records, which might be inefficient.
Any advice?