Check if the constant GEMNAME is defined before use in `assert.rb`.
This is added to prevent an undefined constant error when using
`assert.rb` in other environments - for example, testing CRuby.
- I think "Info" is used only to `skip`, so change to "Skip".
- Changed the default value of `assert` and specify the argument explicitly
at the caller of `assert` because it is unnatural "Assertion failed" is
output even though the assertion doesn't fail.
== Example:
def assert_foo(exp, act)
assert do
assert_equal exp[0], act[0]
assert_equal exp[1], act[1]
end
end
def assert_bar(exp, act)
assert do
skip
end
end
def assert_baz(exp, act)
assert do
assert_equal exp, act
assert_bar exp, act
end
end
assert 'test#skip_in_nested_assert' do
assert_baz 1, 1
end
=== Before this patch:
?..
Info: test#skip_in_nested_assert (core)
- Assertion[1]
Info: Assertion failed (core)
- Assertion[1-2]
Skip: Assertion failed (core)
Total: 3
OK: 2
KO: 0
Crash: 0
Warning: 0
Skip: 1
=== After this patch:
???
Skip: test#skip_in_nested_assert (core)
- Assertion[1]
Skip: assert (core)
- Assertion[1-2]
Skip: assert (core)
Total: 3
OK: 0
KO: 0
Crash: 0
Warning: 0
Skip: 3
When nesting `assert` used in test, it is indented and displayed.
Assertion numbers are concatenated by `"-"` at this time.
The purpose is to match the apparent numbers when failing with `assert_mruby`
which is defined by `mrbgems/mruby-bin-mruby/bintest/mruby.rb` for example.
Child assertions "skip" and "info" are reported as parent assertions "info"
and `$ok_test += 1`. The child assertions "ko" and "crash" are reported as the
parent assertion "ko" and `$ko_test += 1`.
When child assertions are mixed, "ko" takes precedence.
Incompatibility:
- `$mrbtest_assert_idx` takes `nil` or an integer array object.
So far it was `nil` or an integer.
- `$asserts` points to the top of the internal stack in the `assert`.
- `$mrbtest_assert` points to the top of the internal stack in `assert`.
`assert_float` is always passed when expected value and/or actual value are
infinity or NaN. This behavior seems unintentional.
Before this patch:
assert_float(Float::INFINITY, 1.0) #=> pass
assert_float(-Float::INFINITY, 1) #=> pass
assert_float(1, 1/0) #=> pass
assert_float(1, -1/0) #=> pass
assert_float(1.0, Float::NAN) #=> pass
assert_float(Float::NAN, 1) #=> pass
After this patch:
assert_float(Float::INFINITY, 1.0) #=> fail: Expected 1.0 to be Infinity.
assert_float(-Float::INFINITY, 1) #=> fail: Expected 1 to be -Infinity.
assert_float(1, 1/0) #=> fail: Expected Infinity to be 1.
assert_float(1, -1/0) #=> fail: Expected -Infinity to be 1.
assert_float(1.0, Float::NAN) #=> fail: Expected NaN to be 1.0.
assert_float(Float::NAN, 1) #=> fail: Expected 1 to be NaN.
Based on minitest RubyGem.
Example of before this patch:
- Assertion[1] Failed: Expected 1 to be 2
Expected: 2
Actual: 1
- Assertion[2] Failed: Expected [1, 3] to include 2
Collection: [1, 3]
Object: 2
Example of after this patch:
- Assertion[1]
Expected: 2
Actual: 1
- Assertion[2]
Expected [1, 3] to include 2.
For the following reasons:
- Previous behavior is confusable because it's different from test/unit rubygem's `assert_true`
- Tests may pass unintentionally in an inappropriate way; ref #4285#4287
Include the following changes too:
- Extract part of logic with block to a method
- Use `var ||= ...` instead of `var = ... unless var`
- Unify using parentheses for `t_print`
- Change methods order
Mark Delk