BIND 10 #2888: msgq unittest failure on OpenBSD

[BIND 10 Development]

#2888: msgq unittest failure on OpenBSD
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |  vorner
            Priority:  very high     |                       Status:
           Component:  msgq          |  closed
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130423
         Sub-Project:  Core          |                   Resolution:  fixed
Estimated Difficulty:  3             |                 CVSS Scoring:
         Total Hours:  1.71          |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by vorner):

 * status:  reviewing => closed
 * totalhours:  0 => 1.71
 * resolution:   => fixed


Comment:

 Hello

 Replying to [comment:8 jinmei]:
 > This gap also made me realize I might misunderstand the purpose of
 > #1927 and msgq_run_test.py: I thought the subject of #1927 was to
 > write more detailed unit tests and the run_test.py was an attempt of
 > it like the statistics tests do.

 Well, the ticket itself didn't really specify if it should be system or
 unit tests. However, when doing it, I considered:
  * The related ticket #1929 is probably implementable only as system
 tests, #1928 probably too.
  * When mocking the low-level operations, I would have mock out like 50%
 of msgq's code.
  * The „algorithmic“ parts (like subscription management) is already
 covered by unit tests.

 So I decided it needs something like a system test, but not for the whole
 bind10 system, just for msgq. Therefore I didn't call it a system test,
 because it doesn't test the whole system. But unit test isn't enough for
 testing msgq works either. I don't think the unittest/systemtest
 distinction works well.

 I'm OK with deciding to move these (module-level?) tests under system
 tests, so they are not run with make check. It just seems it is not easy
 to attach another test besides the lettuce ones to be just run.

 For the record, I don't think the comparison with stats tests is very
 fitting. Stats tests start other than the tested processes, this one
 starts the testee. Also, statistics don't really need to test the
 communication with other processes, just their merging of the statistics
 data, while the communication is the main purpose of msgq.

 > The branch itself looks okay.  As this is an urgent care issue I think
 > it should be merged now.  I'd leave it to you whether to continue the
 > discussion above and possibly do some development work within this
 > ticket.

 Merged.

 I still don't see what concrete action should be taken to address your
 concerns, so I'm closing the ticket. If you have a concrete idea what to
 do with it, please create a new one.

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