[asterisk-dev] [Code Review] 3152: testsuite: Add a test for SQLite3 backend and custom CDR entries

[Mark Michelson]

-----------------------------------------------------------
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
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20140124/6ec0e8e7/attachment.html>