I’m working on a test plan for a website where some tests are taking the following path:
- Hit the requested URI and get the data rendered inside some table(20 rows per page).
- Make a database query to get the data that is supposed to be rendered in that table.
- Compare the 2 data row by row, they should match.
Is that a correct way of doing functional testing? If that request was an Ajax request, what will be the answer also? Would the answer differ for integration testing?
I have some reason that makes me believe that this is wrong somehow…. still need your opinions guys!
Yes, this could be a productive test. Either you have a fixed data set or you don’t.
If you have a fixed data set, this is much easier to test, because all you’re doing is comparing against a fixed output.
If you don’t have a fixed data set, then you need to duplicate the business logic, effectively duplicating the work already done by the developer. Then you have two sets of logic to maintain.
The second is the best approach because you get two ways of doing the same thing, effectively a peer review of the specification and code. It’s also very expensive in terms of time and resources, which is why most people choose to have a fixed data set.
To answer your question, if your business logic in the query is simple, then you can get a test very easily. However, the value that the test brings isn’t great, because you aren’t testing very much.
If the business logic is complex, you are getting more value from the test, but it’s going to be harder to maintain in the long term.
For me, what your test does bring is a simple integration test that proves that the system reads correctly from the database, and displays the data correctly. This is a good test, even better if it is automated.