@zuhao you are right of course. I did not get that the Pull Request was actually updated and the diff context did not contain the assignment. Sorry for that :sweat: 

As @arthurnn already mentioned, we need to ensure that this reset is taking place. If the assertion before your reset fails, this will skip the reset and tests running afterwards have a polluted environment. A common pattern is:

```ruby
  test "Password digest cost honors bcrypt cost attribute when min_cost is false" do
    original_min_cost, ActiveModel::SecurePassword.min_cost = ActiveModel::SecurePassword.min_cost, false
    original_cost, BCrypt::Engine.cost = BCrypt::Engine.cost, 5

    begin
      ActiveModel::SecurePassword.min_cost = false
      @user.password = "secret"
      assert_equal BCrypt::Engine.cost, @user.password_digest.cost
    ensure
      ActiveModel::SecurePassword.min_cost = original_min_cost
      BCrypt::Engine.cost = original_cost
    end
  end
```

Note that this test leaks `ActiveModel::SecurePassword.min_cost` as well. It might not cause errors down the road but we should clean it up either way. The example above resets both options to it's original state rather than a hardcoded value like `nil`. This is important because the default might change. If that happens, hardcoded resets will no longer reset to the default but themselves leak the state.