Is it a good practice to check the state of a database in acceptance tests?
Consider that one is supposed to write automated acceptance tests for e-commerce system. For example, you want to check that when customer completes checkout operation he has a new order registered in the system that is linked to his account. Now one thing, of course, that you can check is that there are some UI messages displayed like 'Order completed succesfully'. However that does not guarantee that the order is in fact persisted in the db. My question is whether it is OK to additionally verify with querying the DB that order indeed was saved. Or should I verify that inexplicitly in other acceptance test e.g. by checking list of orders (which should not be empty after completing checkout operation succesfully) beforehand performing checkout operation?
you can check is that there are some UI messages displayed like 'Order completed succesfully'. However that does not guarantee that the order is in fact persisted in the db.
Actually it depends. If we're talking Selenium - they do suggest such database-validation:
Another common type of testing is to compare data in the UI against the data actually stored in the AUT’s database. Since you can also do database queries from a programming language, assuming you have database support functions, you can use them to retrieve data and then use the data to verify what’s displayed by the AUT is correct.
However testing the Acceptance criteria should be done only after they are clear enough. If there is no such specific E2E requirement - you shouldn't include this DB check in these tests. You could put them in you functional and integration level, where the SUT architecture allows such black-box approach. If we concider the typical N-tier (UI-Backend-DB), your black-box will be the Middleware - input from UI, [skip all between], output is in DB.
This of course will introduce a bit more complexity and your test will become brittle (which is especially true for the UI ones). Further more you should think for expensive objects and keeping/disposing them properly (e.g. DB connection per suite run).
IMHO you should have all this covered in your auto tests:
it is OK to additionally verify with querying the DB that order indeed was saved. Or should I verify that inexplicitly in other acceptance test e.g. by checking list of orders (which should not be empty after completing checkout operation succesfully) beforehand performing checkout operation
And the only question would be where is the place to put them.
