# Forking and integration tests **URL:** \ **Category:** Rails\ **Created:** [July 19, 2010, 5:40pm UTC](https://www.ruby-forum.com/t/forking-and-integration-tests/191842 "2010-07-19T17:40:04Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![mfb82](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/e274bd/32.png) [@mfb82](https://www.ruby-forum.com/u/mfb82)\ **Post date:** [July 19, 2010, 5:40pm UTC](https://www.ruby-forum.com/t/forking-and-integration-tests/191842/1 "2010-07-19T17:40:04Z")
Hi All, I had a bug in one project, that data get duplicated in the DB due to multiple instances of the application (multiple thins) are accessing the DB at the same time … The typical mistake. Problem fixed. I just need to write a test code that covers the fixed bug. I need to simulate the concurrent requests that can result in the original bug. I thought of many ideas and decided to go with forking 2 or more processes (from within the test code) in which I issue a get request to my controller-action. Setup: MySQL DB, Rails 2.3.5, Ruby 1.9.1, Shoulda and FactoryGirl. Unfortunately this test code doesn’t do the trick. When I try to remove\_connection before forking and then establish\_connection inside the children processes, I don’t find data when asserting. When trying to use the same connection among the parent process and its children, I get into a total mess (due to concurrent access to the db connection). Sample errors from different runs: The famous “MySQL has gone away” Some other times it work perfectly! “Mysql::Error: SAVEPOINT active\_record\_1 does not exist” “undefined method all\_hashes for nil:NilClass” I know that I have so many issues to handle here: concurrency safety, blocking DB adapter, the nature of the testing environment…etc But, is there another approach to handle it? What is the best practice of testing code for concurrency? I know that u may need more details or code sample … but I’m trying to think of the concept itself. Sorry for the long message. Thanks