| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While using `assert_changes`, I came across some unexpected behavior:
if you provide a `to:` argument, and the expression matches but didn't
actually change, the assertion will pass.
The way `assert_changes` reads, I assumed that it would both assert
that there was any change at all, _and_ that the expression changed to
match my `to:` argument.
In the case of just a `from:` argument, `assert_changes` does what I
expect as well. It asserts that the before value `=== from` and that
the after value changed.
My key change is that `assert_changes` will now _always_ assert that
expression changes, no matter what combination of `from:` and `to:`
arguments
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Seeing the previously issued PRs about it, we can avoid the `nil`
comparisons that can happen in `assert_changes` by using plain `assert`
calls.
This is to avoid a deprecation warning about comparing `nil` values in
`assert_equal` for Minitest 5 and a crash in Minitest 6.
You can see the preparations done in [`assert_equal`][ae]. You can also
see that [`assert`][a] does not care about `nil`s.
[ae]: https://github.com/seattlerb/minitest/blob/ca6a71ca901016db09a5ad466b4adea4b52a504a/lib/minitest/assertions.rb#L159-L188
[a]: https://github.com/seattlerb/minitest/blob/ca6a71ca901016db09a5ad466b4adea4b52a504a/lib/minitest/assertions.rb#L131-L142
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
These changes resolve a deprecation warning in `assert_no_changes`
when asserting that an expression evaluates to `nil` before and after
the passed block is evaluated.
The smallest demonstration of this edge case:
```ruby
assert_no_changes "nil" do
true # noop
end
```
Under the covers, this is evaluating
```ruby
assert_equal nil, nil
```
Minitest 5 issues a deprecation warning, and Minitest will fail
completely.
For additional context, the motivations and implications of this change
to Minitest have been discussed at length in [seattlerb/minitest#666][].
[seattlerb/minitest#666]: https://github.com/seattlerb/minitest/issues/666
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
If `from` is nil, in order to avoid the blank is showed.
|
| |
|
|
|
|
|
|
| |
ActiveSupport::Testing::Assertions.
We have a separate module in which have defined Rails' own custom
assertions. So it would be good to keep all custom Rails' assertions in
one place i.e. in this module.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
|
| |
|
|
| |
We used to have `assert_blank` and `assert_presence`. [ci skip]
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
With this we can perform new assertions on the returned value without having
to cache it with an outer variable or wrapping all subsequent assertions inside
the `assert_difference` block.
Before:
```
post = nil
assert_difference -> { Post.count }, 1 do
Post.create
end
assert_predicate post, :persisted?
```
Now:
```
post = assert_difference -> { Post.count } do
Post.create
end
assert_predicate post, :persisted?
```
|
| | |
|
| |
|
|
| |
[ci skip]
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
They don't add any benefits over `assert object.blank?`
and `assert object.present?`
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
| |
Ruby assumes curly braces in foo {} as a block, for hash we need to put parentheses or omit braces
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
objects in the collection
|
| |
|
|
| |
a string
|
| |
|
|
| |
better default failure messages - let's use them
|
| |
|
|
| |
's/[ \t]*$//' -i {} \;)
|
| | |
|
| |
|
|
| |
Signed-off-by: Xavier Noria <fxn@hashref.com>
|
| |
|
|
| |
Signed-off-by: Xavier Noria <fxn@hashref.com>
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
