Which is FALSE about "should_receive"
A. It provides a stand-in for a real method that doesn’t exist yet
B. It would override the real method, even if it did exist
C. It can be issued either before or after the code that should make the call
D. It exploits Ruby’s open classes and metaprogramming to "intercept" a method call at testing time
查看答案
Eventually we will have to write a real find_in_tmdb. When that happens, we should:
A. Replace the call to to_receive in our test with a call to the real find_in_tmdb
B. Ensure the API to the real find_in_tmdb matches the fake one used by to_receive
C. Keep the to_receive seam in the spec, but if necessary, change the spec to match the API of the real find_in_tmdb
D. Remove this spec (test case) altogether since it isn’t really testing anything anymore
Which of these, if any, is not a valid use of should or should_not?
A. result.should_not be_empty
B. 5.should be result
C. result.should_not match /^D'oh!$/
D. All of the above are valid uses
should_receive combines _____ and _____, whereas stub is only _____.
A mock and an expectation, a mock
B. A mock and an expectation, an expectation
C. A seam and an expectation, an expectation
D. A seam and an expectation, a seam
Which of the following kinds of data, if any, should not be set up as fixtures?
A. Movies and their ratings
B. TMDb API key
C. The application's time zone
D. Fixtures would be fine for all of these
微信支付 
支付宝支付