----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3152/#review10688 -----------------------------------------------------------
/asterisk/trunk/tests/cdr/sqlite3/cdr_sqlite3.py <https://reviewboard.asterisk.org/r/3152/#comment20181> There's something I don't like about this method of verifying CDR entries: you can't tell that each of the CDR entries matched a distinct line from test-config.yaml. So for instance, a badly-written test could have a generic line configured that accidentally matches multiple CDR entries. With the way the verifier is written, a single configured line that matches multiple CDR entries would still result in a pass. Similarly, if Asterisk were to emit two identical CDR entries, they'd each match the same line, resulting in a pass. You could alleviate this issue by tracking which line matches the CDR entry you are currently iterating over and removing the line from the list of lines when a match is found. You would lose the niceness of being able to use any(), but you would also more accurately verify the records. - Mark Michelson On Jan. 24, 2014, 5:51 p.m., Matt Jordan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3152/ > ----------------------------------------------------------- > > (Updated Jan. 24, 2014, 5:51 p.m.) > > > Review request for Asterisk Developers. > > > Bugs: ASTERISK-23162 > https://issues.asterisk.org/jira/browse/ASTERISK-23162 > > > Repository: testsuite > > > Description > ------- > > A user reported that, in Asterisk 12, the SQLite3 CDR backend was not > recording any values. This prompted me to write a test to see if I could (a) > reproduce the problem and (b) have a test that verified custom CDR values > (which we don't currently test for, as our CDR CSV library is tied to the > default expected columns). While I wasn't able to reproduce the issue > reporter's problem, this was still a useful test... so here it is. > > This test checks for the following: > * That a sqlite3 CDR backend generates the expected records > * That using the CDR function results in custom values being recorded > * That the userfield values from channels are concatenated during a bridge > operation > * Some other minor, interesting behaviour > > > Diffs > ----- > > /asterisk/trunk/tests/cdr/sqlite3/test-config.yaml PRE-CREATION > /asterisk/trunk/tests/cdr/sqlite3/configs/ast1/extensions.conf PRE-CREATION > /asterisk/trunk/tests/cdr/sqlite3/configs/ast1/cdr_sqlite3_custom.conf > PRE-CREATION > /asterisk/trunk/tests/cdr/sqlite3/configs/ast1/cdr.conf PRE-CREATION > /asterisk/trunk/tests/cdr/sqlite3/cdr_sqlite3.py PRE-CREATION > > Diff: https://reviewboard.asterisk.org/r/3152/diff/ > > > Testing > ------- > > It (mostly) passes with the latest in 12. The 'h' extension will currently > create an unwanted record, but a patch for that will be going up shortly. > > > Thanks, > > Matt Jordan > >
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev