Shulou(Shulou.com)05/31 Report--

This article will explain in detail how to clean up the outdated data in Rspec. The content of the article is of high quality, so the editor shares it for you as a reference. I hope you will have some understanding of the relevant knowledge after reading this article.

Rails Rspec background default transaction

If you use rails-rspec, the following configurations are enabled by default in spec/rails_helper.rb:

RSpec.configuredo | config | config.use_transactional_fixtures=true end

This means that "run each example within a transaction", that is, at the end of the example, all database changes will be rolled back.

How do I get the "transaction device" to "run each example within a transaction"?

After delving into the Rails 4 code base and understanding how it actually works in the background, I found the following. In the setup_fixtures function, Rails calls begin_transaction for each database connection.

Setup_fixtures of Rails 4

In the teardown_fixtures function, Rails calls rollback_transaction for each database connection.

Teardown_fixtures of Rails 4

This also means that if you use multiple databases in your application, the application will create transactions for all databases.

Database records created outside the example will not be rolled back

Because the database transaction surrounds each example, any database records created outside the scope of the example are not rolled back, that is, any database records created in the before (: all), before (: context), or before (: suite) code blocks are not rolled back.

This can lead to race conditions between sample groups rather than between the same set of examples, so be careful when dealing with hook issues.

Context'context 1'do before (: context) do create (: user) # WON'T BE ROLLED-BACK end beforedo create (: user) # will be rolled-back end #... End context'context 2'do before (: context) do create (: user) # WON'T BE ROLLED-BACK end #... End # BY NOW, THERE ARE 2 USER RECORDS COMMITED TO DATABASE

Set up database transactions manually

You can also choose to set up database transactions manually using hook.

RSpec.configuredo | config | config.use_transactional_fixtures=false# DISABLE DEFAULT TRANSACTIONS end before (: example) do ActiveRecord::Base.connection.begin_transaction end after (: example) do conn = ActiveRecord::Base.connection conn.rollback_transactionif conn.transaction_open? End # OR around (: example) do | example | ActiveRecord::Base.transactiondo example.run # ROLLBACK after the example finishes. # This exception is silently swallowed by ActiveRecord. RaiseActiveRecord::Rollback end end

[Rails 4 & Rails 5.0.x] Database transactions are executed by thread

Database connections in Rails 4

As you can see from above, the ActiveRecord database connection is performed on a thread-by-thread basis. Therefore, the default database transactions managed by Rails through use_transactional_fixtures are only available in the main thread.

Technically, according to the transaction rollback strategy, one thread's database records will be independent of other threads. Be aware of this when you need to access database data from one of the other threads, such as Selenium.

[Rails 4 & Rails 5.0.x] acceptance testing of JavaScript driver (Selenium) and Capybara Webkit.

Selenium runs on another thread, so it cannot share transactions with the main thread running RSpec. In order for the client application to access the data in the database, RSpec needs to commit the changes. In such cases, you can allow the data to be submitted and then cleaned up manually.

[Rails 4 & Rails 5.0.x] DatabaseCleaner-- rollback strategy

To solve the above problem, you first need to disable Rails-derived transactions, set config.use_transactional_fixtures to false, or simply delete it. DatabaseCleaner is a gem that provides advanced strategies for cleaning up the database, such as deletion, transaction, or deletion.

The following is a famous gist that uses DatabaseCleaner to deal with the above JS driver problems:

Database transactions are shared between test threads [from Rails 5.1onwards]

Shared database transactions between threads are done by Eileen of the Rails team and published as part of Rails 5.1.

Joined lock_thread

Lock_thread is enabled for testing

On how to clean up the old data in Rspec to share here, I hope the above content can be of some help to you, you can learn more knowledge. If you think the article is good, you can share it for more people to see.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.