)]}'
{"dragonflow/tests/unit/test_mech_driver.py":[{"author":{"_account_id":20229,"name":"Omer Anson","email":"omer.anson@toganetworks.com","username":"oanson"},"change_message_id":"d7c64eb61816b1fa8b718b637218e3ac29212384","unresolved":false,"context_lines":[{"line_number":271,"context_line":"                called_args_dict \u003d ("},{"line_number":272,"context_line":"                    self.nb_api.update_lport.call_args_list[0][1])"},{"line_number":273,"context_line":"                self.assertEqual(port[\u0027revision_number\u0027],"},{"line_number":274,"context_line":"                                 called_args_dict.get(\u0027version\u0027))"},{"line_number":275,"context_line":""},{"line_number":276,"context_line":"    def test_delete_network(self):"},{"line_number":277,"context_line":"        network \u003d self._test_create_network_revision()"}],"source_content_type":"text/x-python","patch_set":2,"id":"3a71b18c_40d97121","line":274,"updated":"2016-12-11 13:10:31.000000000","message":"Same comment here as in https://review.openstack.org/393787 : Is there a way to do this without losing test coverage, e.g. constructing expected and actual dictionaries, and comparing them?","commit_id":"b4c7817e50c3a86efdb4b4e7a68dde64dbeff2db"},{"author":{"_account_id":11159,"name":"Hong Hui Xiao","email":"honghui_xiao@yeah.net","username":"HongHuiXiao"},"change_message_id":"022660b1301231953422e8d4e66a2ebc0470d5f7","unresolved":false,"context_lines":[{"line_number":271,"context_line":"                called_args_dict \u003d ("},{"line_number":272,"context_line":"                    self.nb_api.update_lport.call_args_list[0][1])"},{"line_number":273,"context_line":"                self.assertEqual(port[\u0027revision_number\u0027],"},{"line_number":274,"context_line":"                                 called_args_dict.get(\u0027version\u0027))"},{"line_number":275,"context_line":""},{"line_number":276,"context_line":"    def test_delete_network(self):"},{"line_number":277,"context_line":"        network \u003d self._test_create_network_revision()"}],"source_content_type":"text/x-python","patch_set":2,"id":"3a71b18c_8cc02252","line":274,"in_reply_to":"3a71b18c_40d97121","updated":"2016-12-11 21:41:24.000000000","message":"If we are going to compare the dictionaries, there is no change compared to the old way.\nIn the old way, everytime we add/remove feature to port, the existing test case will break, and we need to update it. The feature list get longer, the harder to update test case, especially for someone who isn\u0027t farmiliar with this part.\n\nSo I think the test case itself should be atomic. One test case for one feature. I have created separated test case for port\u0027s allow-address-pair, port\u0027s securitygroup and remote port in previous patches. And create test case for port\u0027s device option and port\u0027s revision number in this patch. I think we are not losing test coverage in this patch.\n\nNow I will have to rebase the code as we move \"tunnel_key\" from lport\u0027s construction list. This is something bad, and something I want to eliminate through these serial patches.","commit_id":"b4c7817e50c3a86efdb4b4e7a68dde64dbeff2db"}]}