Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce assert_changes and assert_no_changes #25393

Merged
merged 1 commit into from
Jul 20, 2016

Conversation

gsamokovarov
Copy link
Contributor

Those are assertions that I really do miss from the standard
ActiveSupport::TestCase. Think of those as a more general version of
assert_difference and assert_no_difference (those can be implemented
by assert_changes, should this change be accepted).

Why do we need those? They are useful when you want to check a
side-effect of an operation. assert_difference do cover a really
common case, but assert_changes gives us more control. Having a
global error flag? You can test it easily with assert_changes. In
fact, you can be really specific about the initial state and the
terminal one.

error = Error.new(:bad)
assert_changes -> { Error.current }, from: nil, to: error do
  expected_bad_operation
end

assert_changes follows assert_difference and a string can be given
for evaluation as well.

error = Error.new(:bad)
assert_changes 'Error.current', from: nil, to: error do
  expected_bad_operation
end

Check out the test cases if you wanna see more examples.

🍻

@rails-bot
Copy link

r? @chancancode

(@rails-bot has picked a reviewer for you, use r? to override)

@lsylvester
Copy link
Contributor

It might be useful to use === for comparing the to and from values, so that you can use classes, regexps, procs, etc when the exact value of the output is not known. i.e.

assert_changes -> { user.token }, to: /\w{24}/  do
  put :regenerate_token
end

assert_changes -> {article.published_at}, from: nil, to: Time do
  put :publish, params: {id: article.id}
end

@rafaelfranca
Copy link
Member

👍 for @lsylvester comment.

Other than that this seems good to me. @gsamokovarov could you update the PR?

@gsamokovarov
Copy link
Contributor Author

Sure, will look it up in a bit.

@gsamokovarov gsamokovarov force-pushed the introduce-assert-changes branch 2 times, most recently from 7300ee5 to 02278a3 Compare July 17, 2016 08:59
@gsamokovarov
Copy link
Contributor Author

@rafaelfranca updated the PR with case operator support. Thanks for the idea, @lsylvester!

Those are assertions that I really do miss from the standard
`ActiveSupport::TestCase`. Think of those as a more general version of
`assert_difference` and `assert_no_difference` (those can be implemented
by assert_changes, should this change be accepted).

Why do we need those? They are useful when you want to check a
side-effect of an operation. `assert_difference` do cover a really
common case, but we `assert_changes` gives us more control. Having a
global error flag? You can test it easily with `assert_changes`. In
fact, you can be really specific about the initial state and the
terminal one.

```ruby
error = Error.new(:bad)
assert_changes -> { Error.current }, from: nil, to: error do
  expected_bad_operation
end
```

`assert_changes` follows `assert_difference` and a string can be given
for evaluation as well.

```ruby
error = Error.new(:bad)
assert_changes 'Error.current', from: nil, to: error do
  expected_bad_operation
end
```

Check out the test cases if you wanna see more examples.

:beers:
@rafaelfranca rafaelfranca merged commit cc22c9e into rails:master Jul 20, 2016
@dmitry
Copy link
Contributor

dmitry commented Aug 1, 2016

Is there are a gem that provides similar functionality to the older rails apps?

@gsamokovarov gsamokovarov deleted the introduce-assert-changes branch August 1, 2016 13:05
@gsamokovarov
Copy link
Contributor Author

I can backport it in a gem for sure.

@dmitry
Copy link
Contributor

dmitry commented Aug 1, 2016

@gsamokovarov would be great to have this methods as separate gem, as I would like to use assert_changes in the old project (rails 3.2). Or if it could be backported to the rails 3.2 would be also great, but I don't think core guys will allow to do that :)

@gsamokovarov
Copy link
Contributor Author

It's a new feature, it can't be backported to any other version. I'll get the gem out shortly.

@gsamokovarov
Copy link
Contributor Author

@dmitry add the following in your Gemfile and you should be good.

group :test do
  gem 'minitest-assert_changes'
end

🍻

@dmitry
Copy link
Contributor

dmitry commented Aug 1, 2016

@gsamokovarov thanks for gem!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants