Loop between Minitest/AssertTruthy and Minitest/AssertWithExpectedArgument when passing msg option to assert

[hjeebus]

desc

I think there is an issue when passing the optional argument msg that is allowed for all assert* methods. When using that optional argument i think the gem gets confused and thinks you want to test equality between the first argument (the test) and the second optional argument (msg). i've added more context to the expected behavior section with code examples.

ref: https://docs.ruby-lang.org/en/2.1.0/MiniTest/Assertions.html

---

Expected behavior

I expect Minitest/AssertWithExpectedArgument not to be raised when passing optional msg argument to assert

Actual behavior

When passing msg rubocop complains about using assert_equal(test, msg)

Steps to reproduce the problem

given:

  def assert_routes_get(path, msg = nil)
    msg = message(msg) { "Expected GET #{path} to be routable" }

    assert(routable?(method: :get, path:), msg)
  end

when:
$ rubocop

then:

C: Minitest/AssertWithExpectedArgument: Did you mean to use assert_equal(routable?(method: :get, path:), msg)?
    assert(routable?(method: :get, path:), msg)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

given:

  def assert_routes_get(path, msg = nil)
    msg = message(msg) { "Expected GET #{path} to be routable" }

    assert_equal(true, routable?(method: :get, path:), msg)
  end

when:
$ rubocop -a

then:

C: [Corrected] Minitest/AssertTruthy: Prefer using assert(routable?(method: :get, path:), msg).
    assert_equal(true, routable?(method: :get, path:), msg)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

and we are back to the first example...

RuboCop version

$ bundle exec rubocop -V
1.41.1 (using Parser 3.1.3.0, rubocop-ast 1.24.0, running on ruby 3.1.2) [arm64-darwin21]
  - rubocop-minitest 0.25.0
  - rubocop-performance 1.15.1
  - rubocop-rails 2.17.3

[fatkodima]

rubocop-minitest/lib/rubocop/cop/minitest/assert_with_expected_argument.rb

Lines 9 to 11 in b97ae78

	# @safety
	# This cop is unsafe because it is not possible to determine
	# whether the second argument of `assert` is a message or not.

So I think, the best solution is to just disable this cop for that line.

[koic]

I've opened #206. The second argument to the assert method named message and msg is allowed. Because their names are inferred as message arguments.