The tests I like to write are usually of the form:

Assume we are testing software that posts and adjusts trades

  • Take a fresh copy of the database and populate it with pre-frozen data as needed (say, a trade)

  • Take test case data (trade change message)

  • Pass that data to your software (whole software, so this is closer to integration test than unit test). In this case, let the software accept the trade change message and hopefully amend the trade in the database.

    • The software is configured to point to your fresh copy of database
  • Check the database, verify that the resulting data is 100% matching your "expected data" for test case.

This seems to be different from integration testing for me, because we are mocking/isolating the environment completely (fresh database, custom network port number etc...), so in a way conceptually it seems closer to a mocked unit test, except at integration test scale.

Is there a formal QA term for this kind of test?

  • Are you using the same database/integration point software as you would in your standard testing and production? If so, this is just a smart way to do integration testing.
    – Paul Muir
    Oct 12, 2016 at 16:47
  • @PaulMuir - yes, simply fresh test copies (actually, for DB, we even use the same server, just place a new copy of the tables in a special test database on that server)
    – DVK
    Oct 12, 2016 at 16:58
  • It just sounds like you've created a test environment.
    – J Doe
    Oct 12, 2016 at 17:00
  • Is the entire process automated end-to-end?
    – corsiKa
    Oct 12, 2016 at 17:41
  • @corsiKa - let's assume that the answer is yes, to avoid over-broadening the question (since that's the end goal of such tests anyway).
    – DVK
    Oct 12, 2016 at 17:53

2 Answers 2


So, you're testing identical integrations as your environment with relatively static data?

I would consider this an easily repeatable integration test. Essentially you just set up a smart way to do it. Often times I will do similar steps with integration-level unit tests, though usually not to the extreme you are going.

To me the term would be integration testing.


You are creating a copy of the production environment as a test environment.

I would say do not worry too much of which term you are using, as the boundaries for different tests are not black-white defined. In your case, there are hints of:

  • Integration test
  • User acceptance test
  • System test
  • Unit test

If the reason for you to name it formally is to document it properly, then give it a name then explain it like you did here. People will understand.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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