> On Jan. 24, 2014, 1:55 p.m., Mark Michelson wrote: > > /asterisk/trunk/tests/cdr/sqlite3/cdr_sqlite3.py, lines 128-139 > > <https://reviewboard.asterisk.org/r/3152/diff/1/?file=53112#file53112line128> > > > > 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.
Yeah, I had to go with this method as there's a race condition between the two Local channels hanging up. The order of the entries in the CDR wasn't guaranteed. Removing a matched CDR is an easy fix. - Matt ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/3152/#review10688 ----------------------------------------------------------- On Jan. 24, 2014, 11:51 a.m., Matt Jordan wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviewboard.asterisk.org/r/3152/ > ----------------------------------------------------------- > > (Updated Jan. 24, 2014, 11:51 a.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
