**TL,DR: *don’t define any methods with names name, message, time, pass in Minitest::Unit test cases unless you really want to override those of Minitest::TestCase.*
When writing Minitest::Unit tests, it’s convenient to use test case’s instance methods as kind of RSpec’s lazy-evaluated let-blocks or various helper methods.
class TrialPeriodVideoDownloadTest < ActiveSupport::TestCase
def user
users(:trial_period_bob)
end
def video
videos(:fullhd_video_private)
end
test 'trial user can download private video' do
travel_to user.registered_at
assert VideoPolicy.new(user, video).download?
travel_back
end
test 'trial user cannot download private video after trial ended' do
travel_to user.registered_at + 32.days
refute VideoPolicy.new(user, video).download?
travel_back
end
end
Note: I am extending ActiveSupport::TestCase for this nice test "verify something" DSL and for other handy features provided by ActiveSupport::Testing, but the problem concerns Minitest::TestCase, which is being inherited behind the scenes.
In this case, when only one user and video are involved in the test, it seems reasonable to name the methods user and video accordingly, and not trial_user, user_bob and fullhd_private_video to distinct them from other tested objects.
One thing to keep in mind when using such general names for methods is that Minitest::TestCase has its own instance methods. Consider this case, quite similar by its spirit to the previous:
class MessageDeliveryTest < ActiveSupport::TestCase
def message
messages(:draft_from_bob_to_alice)
end
test 'changes status to sent after sending' do
MessageDelivery::Send.new(message).perform
assert message.reload.status?
end
test 'changes status to delivered after delivering' do
MessageDelivery::Deliver.new(message).perform
assert_equal 'delivered', message.reload.status
end
end
Surprisingly, one of these tests will fail with a mysterious error message: ArgumentError: wrong number of arguments (2 for 0), with lines def message and assert_equal 'delivered', message.reload.status in backtrace.
It becomes clear after looking on Minitest::Assertions#assert_equal code:
def assert_equal exp, act, msg = nil
msg = message(msg, E) { diff exp, act }
assert exp == act, msg
end
Apparently, we unintentionally overloaded an instance method message, used internally by the test case for displaying customized failure messages.
Fortunately there are not many methods with such general names which can possibly cause confusion. From a brief eye-scan of contents of Minitest::TestCase.instance_methods, I can list only four names which people might want (but shouldn't, for the reason explained above) to use for helper methods in their test cases: time, message, pass (I can imagine an app having a Pass model for passports), name. There are many other methods, but their names are too specific. If somebody overloads assert_in_epsilon, we can assume one knows what he’s doing, but overloading of message, name or time may be unintentional and can lead to unexpected results.
It’s fair to note that Minitest::Spec warns its users when they try to use these reserved names for let-blocks. Try to define things like:
let(:name) { 'Bob' }
–and your test won’t load:
ArgumentError: let ‘name’ cannot override a method in Minitest::Spec. Please use another name.
Minitest::Unit on the other hand is more straightforward and lets you do whatever you want.
Top comments (0)