CODEWITHSUNDEEP
testingautomated-testsintegration-testing
Guy
Guy

Reputation: 67380

Why cleanup a DB after a test run?

I have several test suites that read and write data from a dedicated database when they are run. My strategy is to assume that the DB is in an unreliable state before a test is run and if I need certain records in certain tables or an empty table I do that setup before the test is run.

My attitude is to not cleanup the DB at the end of each test suite because each test suite should do a cleanup and setup before it runs. Also, if I'm trying to "visually" debug a test suite it helps that the final state of the DB persists after the tests have completed.

Is there a compelling reason to cleanup a DB after your tests have run?

Upvotes: 2

Views: 2847

Answers (3)

Pankaj Kumar Katiyar
Pankaj Kumar Katiyar

Reputation: 1494

In addition to above answers, I'll add few more points:

  1. DB shouldn't be cleaned after test because thats where you've your test data, test results and all history which can be referred later on.
  2. DB should be cleaned only if you are changing some application setting to run your / any specific test, so that it shouldn't impact other tester.

Upvotes: 0

ekostadinov
ekostadinov

Reputation: 6950

In addition to the previous answer I'd like to also mention that this is more suitable when executing Integration tests. Since Integrated modules work together and in conjunction with infrastructure such as message queues and databases + each independent part works correctly with the services it depends on.

This

cleanup a DB after a test run

helps you to Isolate Test Data. A best practice here is to use transactions for database-dependent tests (e.g.,component tests) and roll back the transaction when done. Use a small subset of data to effectively test behavior. Consider it as Database Sandbox – using the Isolate Test Data pattern. E.g. each developer can use this lightweight DML to populate his local database sandboxes to expedite test execution.

Another advantage is that you Decouple your Database, so ensure that application is backward and forward compatible with your database so you can deploy each independently. Patterns like Encapsulate Table with View, and NoSQL databases ensure that you can deploy two application versions at once without either one of them throwing database-related errors. It was particularly successful in a project where it was imperative to access the database using stored procedures.

All this is actually one of the concepts that is used in Virtual test labs.

Upvotes: 1

Blake
Blake

Reputation: 308

Depends on your tests, what happens after your tests, and how many people are doing testing.

If you're just testing locally, then no, cleaning up after yourself isn't as important ~so long as~ you're consistently employing this philosophy AND you have a process in place to make sure the database is in a known-good state before doing something other than testing.

If you're part of a team, then yes, leaving your test junk behind can screw up other people/processes, and you should clean up after yourself.

Upvotes: 2

Related Questions