BIND 10 #527: refactoring auth/query_unittests

[BIND 10 Development]

#527: refactoring auth/query_unittests
-------------------------------------+-------------------------------------
                 Reporter:  jinmei   |                Owner:  jinmei
                     Type:  task     |               Status:  reviewing
                 Priority:  major    |            Milestone:  A-Team-
                Component:           |  Sprint-20110126
  b10-auth                           |           Resolution:
                 Keywords:           |            Sensitive:  0
Estimated Number of Hours:  2.0      |  Add Hours to Ticket:  0
                Billable?:  1        |          Total Hours:  0
                Internal?:  0        |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 It's nice you took this, the MockZone was getting on my nerves as well a
 little. But I have few smaller suggestions:
  * It might be worth having another overloaded wrapper for rrsetsCheck,
 taking const std::string&, most of the times it would save one line of
 code to simply pass the string.
  * If rrsetsCheck gets confused if someone puts the same tuple of (name,
 type, class) into the result we check, how much confused results would it
 give? I believe that having the same tuple there means bug, would it fail
 the test, even with a wrong error message at last?
  * I didn't see the doxygen comment near headerCheck function. I know it
 didn't have it and you just moved it, but one would be nice.
  * Looking at the tests, if there was a single call that would combine
 headerCheck and 3 rrsetsCheck calls with the three sections would save a
 lot of code as well. Would you like to introduce such a wrapper?
  * The MX test doesn't test the authority section. It probably didn't
 before as well, but every other test seems to do so, maybe for
 consistency, it should be added?

 Anyway, there's nothing serious. If you need this for #526, you probably
 don't have to wait for the next round of review (I don't expect there
 would be anything substantial), you can just probably merge it to your
 #526 branch before merging to trunk.

-- 
Ticket URL: <http://bind10.isc.org/ticket/527#comment:4>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development