In functional testing, should I compare all tabular data rendered in the browser with the one coming from the DB?

Question

I'm working on a test plan for a website where some tests are taking the following path:

1. Hit the requested URI and get the data rendered inside some table(20 rows per page).
2. Make a database query to get the data that is supposed to be rendered in that table.
3. 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!

Answer 1

This seems fine for functional testing. Integration testing in my mind has to do with the testing of different technologies or components that are supposed to work together which is generally broader than functional testing. But of course this sort of testing could also be considered integration testing, depending on how your application is put together and where the testing is happening in the lifecycle of your development. For example it may be that in order for this site to work you have to put together a few components that were developed independently; this might be one of the tests to validate that the integration works.

Don't see how this being Ajax or not has anything to do with making the answer different.

Answer 2

I will likely be a dissenting opinion here, but I don't consider this to be a productive test. What you are doing is simply duplicating the code which produces the page. And any time you introduce duplicated code (even across departments) you'll be looking at defects cropping up long-term.

It is far better to load the DB with known data (either through the app, or directly) and then check that the output matches what you'd expect. This also ensures that your DB layer, or DB itself, hasn't modified the data in a way you do not expect.

That is:

1. Load known data (preferably through the app itself)
2. Load the requested URI
3. Check that displayed data matches your known data

Answer 3

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.