BIND 10 #2377: define dns::MasterLoad class

[BIND 10 Development]

#2377: define dns::MasterLoad class
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  jinmei
            Priority:  medium        |                       Status:
           Component:  libdns++      |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20121218
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  7             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  loadzone-ng
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:28 vorner]:

 > > > Anyway, the current code does handle the EOF even in successful
 case, as it
 > > > calls the function to create Rdata ‒ it does that. I added a test to
 confirm it.
 > >
 > > I don't think we need a test for that case in `MasterLoader`; it's
 > > beyond the responsibility to it (As commented above, I misunderstood
 > > the original BIND 9 code on this point).  I suggest removing the
 > > noEOLN test.
 >
 > Is there any reason to remove the test, when it's already written?

 Because it doesn't test `MasterLoader`'s behavior itself, and is just
 yet another and indirect test of createRdata().  IMO, tests should be
 generally both necessary and sufficient; in many cases (due to
 laziness) they are not sufficient, and adding more tests wouldn't be a
 problem.  But adding a redundant one when it's already sufficient is
 IMO not a good practice, either, just like any redundant/unused code
 isn't good and is better to be cleaned up rather than allowing it to
 stay just because it has been written.

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