<p>When you are doing integration tests with either just your data access layer or the majority of the application stack. What is the best way prevent multiple tests from clashing with each other if they are run on the same database?</p>

[{'answer_id': 61720, 'author': 'Free Wildebeest', 'author_id': 1849, 'author_profile': 'https://Stackoverflow.com/users/1849', 'pm_score': 3, 'selected': False, 'text': '<p>For simple database applications I find using <a href="http://www.sqlite.org/" rel="noreferrer">SQLite</a> invaluable. It allows you to have a unique and standalone database for each test.</p>\n\n<p>However it does only work if you\'re using simple generic SQL functionality or can easily hide the slight differences between SQLite and your production database system behind a class, but I\'ve always found that to be fairly easy in the SQL applications I\'ve developed.</p>\n'}, {'answer_id': 61721, 'author': 'Orion Edwards', 'author_id': 234, 'author_profile': 'https://Stackoverflow.com/users/234', 'pm_score': 4, 'selected': True, 'text': "<p>Transactions.</p>\n\n<p>What the ruby on rails unit test framework does is this:</p>\n\n<pre><code>Load all fixture data.\n\nFor each test:\n\n  BEGIN TRANSACTION\n\n    # Yield control to user code\n\n  ROLLBACK TRANSACTION\n\nEnd for each\n</code></pre>\n\n<p>This means that</p>\n\n<ol>\n<li>Any changes your test makes to the database won't affect other threads while it's in-progress</li>\n<li>The next test's data isn't polluted by prior tests</li>\n<li>This is about a zillion times faster than manually reloading data for each test.</li>\n</ol>\n\n<p>I for one think this is pretty cool</p>\n"}, {'answer_id': 61722, 'author': 'Garry Shutler', 'author_id': 6369, 'author_profile': 'https://Stackoverflow.com/users/6369', 'pm_score': 0, 'selected': False, 'text': "<p>I wanted to accept both Free Wildebeest's and Orion Edwards' answers but it would not let me. The reason I wanted to do this is that I'd come to the conclusion that these were the two main ways to do it, but which one to chose depends on the individual case (mostly the size of the database).</p>\n"}, {'answer_id': 61764, 'author': 'Techboy', 'author_id': 2699, 'author_profile': 'https://Stackoverflow.com/users/2699', 'pm_score': 0, 'selected': False, 'text': '<p>Also run the tests at different times, so that they do not impact the performance or validity of each other.</p>\n'}, {'answer_id': 73274, 'author': 'Bradley Harris', 'author_id': 10503, 'author_profile': 'https://Stackoverflow.com/users/10503', 'pm_score': 1, 'selected': False, 'text': '<p>Just to add to Free Wildebeest\'s answer I have also used <a href="http://hsqldb.org/" rel="nofollow noreferrer">HSQLDB</a> to do a similar type testing where each test gets a clean instance of the DB.  </p>\n'}, {'answer_id': 95312, 'author': 'Community', 'author_id': -1, 'author_profile': 'https://Stackoverflow.com/users/-1', 'pm_score': 0, 'selected': False, 'text': '<p>While not as clever as the Rails unit test framework in one of the other answers here, creating distinct data per test or group of tests is another way of doing it.  The level of tediousness with this solution depends on the number of test cases you have and how dependant they are on one another.  The tediousness will hold true if you have one database per test or group of dependant tests.</p>\n\n<p>When running the test suite, you load the data at the start, run the test suite, unload/compare results making sure the actual result meets the expected result.  If not, do the cycle again.  Load, run suite, unload/compare.</p>\n'}]
['https://Stackoverflow.com/questions/61718', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/6369/']