Take the 2-minute tour ×

I have a continuous integration build server (using Team City). When people check code in, I'd like to run a set of tests which run through a set of functional cases such as:

  • Using an administrator account, I can create a document
  • If I belong to the 'Editor' role, then I can access document x and document y.

and so on.

We have a number of unit tests which cover individual functions, but we really want this quick 'smoke test' to see if anything discrete has slipped through the net.

Should I:

  1. Create a 'dummy database' with pre-populated users, permissions, documents, and create the tests to use data from this database?
  2. Use some sort of mocking framework for this? What are the advantages / disadvantages here?

Or, is my thinking completely off?

Appreciate your thoughts.

share|improve this question
add comment

2 Answers

up vote 3 down vote accepted

If you are curious about the tradeoffs around mock objects, there are entire websites and books devoted to the subject. I will restrict my answer to the specific problem you described.

I never replace a real system with a mock system unless the real system does not meet my needs; a mock system requires time to write and maintain, and when a test fails, you will have to ask yourself whether the problem is in the product or in your mock system. You have not mentioned anything that would prevent using a dummy database for your smoke test. While you did not specify whose database technology you are using, most database vendors provide an easy and reasonably fast way to restore a database from a backup and to rename a database (e.g. from "DB_backup" to "test_123").

(If you suspect there are reasons why using a dummy database will not meet your needs, please revise your question to include those issues.)

share|improve this answer
Hi, thanks for your answer. We currently do not have any reason to not use a dummy database. I think it would suit our needs fine. I'm new to QA and generally needed verification that using such a DB would not be going against any common QA thought or best practices. –  christofr Sep 14 '11 at 14:56
The only thing I would be worried about is ongoing database development, e.g., new columns or tables being added that the code expects to have there could invalidate your old data. Just make sure you have an idea of how much work you will go through to keep your dummy DB up-to-date. –  Ethel Evans Sep 14 '11 at 17:50
add comment

What you can do is run your tests within a transaction and assert your expected outcomes. When you are finished you can roll back the transaction. This will leave your database in the original state. This is easy to set up using spring with junit. You would have to have your developers implement this test for you. You can also use Selenium 2 or Webdriver to run your application in a web browser if it's a web application.

share|improve this answer
add comment

Your Answer


