Take the 2-minute tour ×
Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It's 100% free, no registration required.

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

2 Answers 2

up vote 4 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
2  
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

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
    
This could work for unit test but for integration/functionality test? –  Peter Masiar Jul 11 at 17:35

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.