Currently, after every action that adds or changes data, we verify that that data was successfully added/changed in the database by querying the tables directly. I feel this is redundant because that data is already being pulled by the application and is displayed correctly (or incorrectly) in the application. Wouldn't any data inconsistencies expose themselves in the application itself?
This is the jist of the issue, but I will provide a simplified test case to expand on what I'm talking about:
- Go to user "John Smith" profile and update his phone number from "(999) 999-9999" to "(666) 666-6666" and click the save button in the application
- Verify application displays "Successfully changed user profile"
- Go to preview profile and verify John Smith's profile reflects the changes
- Verify table USER_PROFILE in DBusers database updated with changes
Is it necessary to check the table in the database if we've already verified the application is displaying the data correctly? The application is ALREADY pulling the data from the database table, so obviously if the application is displaying the data correctly then the data in the database is correct. Am I missing something?
Thanks for your input.
More info: To me, it seems that the only practical purpose for verifying a database directly (for our circumstances) would be to verify that any data replication is successful. We have web and console based apps that use separate DBMSs. The two we use are SQL Server and DB2. After specific data is added to SQL Server, a job runs that replicates it to DB2. They have different structures, so the tables / fields are all different between the two. I can understand verifying this replication has performed successfully.