BIND 10 #466: duplicate code in xfrout

[BIND 10 Development]

#466: duplicate code in xfrout
-------------------------------------+-------------------------------------
                 Reporter:  jinmei   |                Owner:  zzchen_pku
                     Type:  defect   |               Status:  reviewing
                 Priority:  minor    |            Milestone:  y2 12 month
                Component:  xfrout   |  milestone
                 Keywords:           |           Resolution:
Estimated Number of Hours:  0.0      |            Sensitive:  0
                Billable?:  1        |  Add Hours to Ticket:  0
                Internal?:  0        |          Total Hours:  0
-------------------------------------+-------------------------------------

Comment (by zzchen_pku):

 Replying to [comment:7 jinmei]:
 > I've made some additional suggested updates.  Those include:
 >  - replaced "NS" with "name server" because "NS" looks like an RR type
 and can be confusing.
 >  - s/soa/SOA
 Okay, thanks.
 > '''sqlite3_ds.py'''
 > I see some valid points here.  In particular, it's true that writing
 unittests for DB related stuff is difficult (in fact, in a commoly adoped
 definition it wouldn't be considered "unittest").  However:
 >  - it still cannot be a reason for skipping tests, even if it's not test
 "driven".
 >  - in case of sqlite3 it should still be relatively easier to provide
 tests because we only need library calls (and pre-populated test DB file),
 i.e, we don't need a separate process or network-based transactions.
 >  - in fact, the C++ version of sqlite3 data source has detailed "unit"
 tests.
 >  - so I suspect the main reason why the python version of sqlite3 data
 source didn't have tests was because we made compromise due to the hard
 deadline for the year1 deliverable (or we were simply lazy:-)
 >  - whether this could/should be test "driven" may be debatable, but for
 the above reasons in this specific case I believe it can, and if it can I
 believe it shoud.
 >  - at the bottom line I don't see a valid excuse to skip tests for the
 sqlite3 data source python module.
 >  - and, in fact, it looks like you found and fixed a bug thanks to
 writing the test:-)
 Okay.
 > As for documentation, I'd like to use the pydoc style comments.
 Eventually that would apply to other functions of this file.  I wouldn't
 request that within the scope of this ticket, but let's at least use it
 for newer code.
 I updated the sqlite3_ds comments by using pydoc style.
 > '''sqlite3_ds_test.py'''
 >  - I suspect the copyright year should be 2011:-)
 Yeah, I just copied it from another file, thanks for checking:-)
 >  - in this case I suspect we cannot use mocks because this module is our
 interface to sqlite3.  For tests of a user app of this module such as
 xfrout we can use a mock data source, but tests for sqlite3 specific
 module should use sqlite3.
 >  - exception case(s) should also be tested.
 Done.

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