assert_equal in MiniTest

@chrisbodhi I also find it difficult to understand how the test cases are passed. I’ve checked them and they do, but in my opinion test_name_sticks should fail as every call to name will append a new random name to the previous one instead of returning the same string. For example, if we run a simple test:

robot = Robot.new
2.times{puts robot.name}
we get:
QF658
QF658YV199
making it clear that the test should fail. —franrodalg

If I’m understanding the question, it looks like that assert_equal calls robot.name twice; since the two return values are different, the test should fail. I wasn’t sure how that method works, so I peeked at the source here [thankfully, it’s also written in Ruby]. The method takes two values: the expected output and the actual output. It uses the system’s diff tool to compare the two arguments and then proceeds based on the value returned by the diff.

I haven’t used a lot of the Unix tools before, so I fired up pry and copied in my Robot class. I created a new robot instance [you can see in the returned object that the @name value is instantiated as an empty string] and used %x to run system [Unix] commands in the REPL, passing in the string-interpolated robot.name twice.

robot = Robot.new
=>#<Robot:0x007fff134761b0 @name="">
%x(diff -u #{robot.name} #{robot.name})
diff: XP677XA768: No such file or directory
diff: XP677XA768: No such file or directory
=>""

I initially thought the diff would compare robot.name as a static object [something like nombre = robot.name and then diff -u #{nombre} #{nombre}], so I was surprised to see that the method gets called twice. However, it seems that the methods are running before the diff tool does its thing. I’m willing to wager that the object ID is the same for both return values. So, even though the return value doesn’t meet the requirements for a robot name [two letter, three numbers], the value does persist and the test passes.

Find the entire discussion here.