)]}'
{"trove/tests/unittests/guestagent/test_api.py":[{"author":{"_account_id":9664,"name":"amrith","email":"amrith.kumar@gmail.com","username":"amrith"},"change_message_id":"5c2ceb7200ec6ae5f52efca4f2e7518933bedbf6","unresolved":false,"context_lines":[{"line_number":49,"context_line":""},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"class ApiTest(trove_testtools.TestCase):"},{"line_number":52,"context_line":"    @mock.patch.object(rpc, \u0027get_client\u0027)"},{"line_number":53,"context_line":"    def setUp(self, *args):"},{"line_number":54,"context_line":"        super(ApiTest, self).setUp()"},{"line_number":55,"context_line":"        self.context \u003d context.TroveContext()"}],"source_content_type":"text/x-python","patch_set":5,"id":"7a016987_2861ffa8","line":52,"updated":"2015-05-27 12:45:05.000000000","message":"is this right?\n\nHow, is this any different from mocking in setUp if you can unmock in tearDown?","commit_id":"ab2cea10b64ee187cbd4e5aa511e23352737ad48"},{"author":{"_account_id":7806,"name":"Sushil Kumar","email":"skm.net@gmail.com","username":"sushilkm"},"change_message_id":"6383a81e8fb4d6faf6e512889a96df88dda55df8","unresolved":false,"context_lines":[{"line_number":49,"context_line":""},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"class ApiTest(trove_testtools.TestCase):"},{"line_number":52,"context_line":"    @mock.patch.object(rpc, \u0027get_client\u0027)"},{"line_number":53,"context_line":"    def setUp(self, *args):"},{"line_number":54,"context_line":"        super(ApiTest, self).setUp()"},{"line_number":55,"context_line":"        self.context \u003d context.TroveContext()"}],"source_content_type":"text/x-python","patch_set":5,"id":"7a016987_684937b7","line":52,"in_reply_to":"7a016987_2861ffa8","updated":"2015-05-27 12:53:26.000000000","message":"So, using the patch.object is the agreed (suggested) approach instead of mocking and unmocking.\n\nAlso, I preferred this over unmocking because there was no teardown written earlier.","commit_id":"ab2cea10b64ee187cbd4e5aa511e23352737ad48"},{"author":{"_account_id":10215,"name":"Peter Stachowski","email":"peter@tesora.com","username":"peterstac"},"change_message_id":"a6aafae0ab2f8da4e2736b7cef9def3b5157e58b","unresolved":false,"context_lines":[{"line_number":49,"context_line":""},{"line_number":50,"context_line":""},{"line_number":51,"context_line":"class ApiTest(trove_testtools.TestCase):"},{"line_number":52,"context_line":"    @mock.patch.object(rpc, \u0027get_client\u0027)"},{"line_number":53,"context_line":"    def setUp(self, *args):"},{"line_number":54,"context_line":"        super(ApiTest, self).setUp()"},{"line_number":55,"context_line":"        self.context \u003d context.TroveContext()"}],"source_content_type":"text/x-python","patch_set":5,"id":"7a016987_0b5aba83","line":52,"in_reply_to":"7a016987_2861ffa8","updated":"2015-05-27 14:19:04.000000000","message":"There is a subtle difference here over doing the mock in setUp.  In this case, the object (rpc.get_client) is *only* mocked in the setUp method (in the test methods it\u0027s no longer mocked).  If setUp is the only place it\u0027s used, then it\u0027s done correctly - keeps the mock scope down.  Putting it inside of setUp (and scheduling it for destruction) would only be necessary if it\u0027s needed in the actual tests - not just in setUp - and that doesn\u0027t appear to be the case here.","commit_id":"ab2cea10b64ee187cbd4e5aa511e23352737ad48"}]}