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鈥檒l 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

Projects
None yet
7 participants
@gsamokovarov
Contributor

gsamokovarov commented Jun 13, 2016

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

This comment has been minimized.

rails-bot commented Jun 13, 2016

r? @chancancode

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

@lsylvester

This comment has been minimized.

Contributor

lsylvester commented Jul 15, 2016

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

This comment has been minimized.

Member

rafaelfranca commented Jul 17, 2016

馃憤 for @lsylvester comment.

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

@gsamokovarov

This comment has been minimized.

Contributor

gsamokovarov commented Jul 17, 2016

Sure, will look it up in a bit.

@gsamokovarov gsamokovarov force-pushed the gsamokovarov:introduce-assert-changes branch 2 times, most recently Jul 17, 2016

@gsamokovarov

This comment has been minimized.

Contributor

gsamokovarov commented Jul 17, 2016

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

Introduce `assert_changes` and `assert_no_changes`
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.

馃嵒

@gsamokovarov gsamokovarov force-pushed the gsamokovarov:introduce-assert-changes branch to 16f24cd Jul 17, 2016

@rafaelfranca rafaelfranca merged commit cc22c9e into rails:master Jul 20, 2016

2 checks passed

codeclimate Code Climate has skipped analysis of this commit.
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@dmitry

This comment has been minimized.

Contributor

dmitry commented Aug 1, 2016

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

@gsamokovarov gsamokovarov deleted the gsamokovarov:introduce-assert-changes branch Aug 1, 2016

@gsamokovarov

This comment has been minimized.

Contributor

gsamokovarov commented Aug 1, 2016

I can backport it in a gem for sure.

@dmitry

This comment has been minimized.

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

This comment has been minimized.

Contributor

gsamokovarov commented Aug 1, 2016

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

@gsamokovarov

This comment has been minimized.

Contributor

gsamokovarov commented Aug 1, 2016

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

group :test do
  gem 'minitest-assert_changes'
end

馃嵒

@dmitry

This comment has been minimized.

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