[asterisk-dev] [Code Review] Unit Test Framework

[Matthew Nicholson]

> On 2009-12-17 08:59:10, Matthew Nicholson wrote:
> > /trunk/tests/test_heap.c, lines 233-248
> > <https://reviewboard.asterisk.org/r/447/diff/2/?file=7570#file7570line233>
> >
> >     Looking at this further with inspriation from boost.test and module.h, I think these registration functions can be replaced with a  modified AST_TEST_DEFINE allowing users to define and register tests in one step.  If AST_TEST_DEFINE, (or a similar macro) created registration functions with __attribute((constructor)) and __attribute__((destructor)) like AST_MODULE_INFO, then calls to AST_TEST_REGISTER and AST_TEST_UNREGISTER could be avoided. An eample follows.
> >     
> >     #define AST_TEST_DEFINE(hdr) static enum ast_test_result_state hdr(struct ast_test_info *info, enum ast_test_command cmd, struct ast_test_args *args)
> >     
> >     #define AST_TEST_AUTO(hdr) \
> >     AST_TEST_DEFINE(hdr); \
> >     static void __attribute__((constructor)) __test_reg_hdr() \
> >     { \
> >     	AST_TEST_REGISTER(hdr); \
> >     } \
> >     static void __attribute__((destructor)) __test_unreg_hdr() \
> >     { \
> >     	AST_TEST_UNREGISTER(hdr); \
> >     } \
> >     AST_TEST_DEFINE(hdr)
> >     
> >     This new macro would be used as follows:
> >     
> >     AST_TEST_AUTO(my_automatically_registered_test_with_a_really_long_name)
> >     {
> >     	return AST_TEST_NOT_RUN;
> >     }
> >
> 
> Russell Bryant wrote:
>     The problem with this approach is the lack of control over constructor firing order.  To illustrate this problem, imagine you have placed a unit test in main/channel.c.  Also, note that in main/test.c, there is a constructor that fires to initialize the global test list lock.  Now, you don't know which will fire first when the application starts.  You end up with the possibility of using the lock before it is properly initialized.
>     
>     I would much rather require register/unregister than have to deal with constructor ordering dependencies.

It is possible to control the order of the constructors and destructors by passing a integer priority argument (lower numbers mean higher priorities for constructors, the reverse for destructors).  These priorities could be used to work around these ordering issues, although that adds some complexity to things.

static void __attribute__((constructor(0))) __test_reg_hdr() ...

The specific case you cite could be solved by hard coding the priorities so that the global test list lock is initialized before any registration functions use it.  There may be other cases where order matters.


- Matthew


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/447/#review1321
-----------------------------------------------------------


On 2009-12-17 12:07:21, David Vossel wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/447/
> -----------------------------------------------------------
> 
> (Updated 2009-12-17 12:07:21)
> 
> 
> Review request for Asterisk Developers and Russell Bryant.
> 
> 
> Summary
> -------
> 
> The Unit Test Framework is a new API that manages registration and execution of unit tests in Asterisk with the purpose of verifying the operation of C functions.
> 
> The Framework consists of a single test manager accompanied by a list of registered test functions defined within the code.  A test is defined, registered, and unregistered from the framework using a set of macros which allow the test code to only be compiled within asterisk when the TEST_FRAMEWORK flag is enabled in menuselect.  This allows the test code to exist in the same file as the C functions it intends to verify.  Registered tests may be viewed and executed via a set of new CLI commands.  CLI commands are also present for generating and exporting test results into xml and txt formats.
> 
> For more information and use cases please refer to the documentation provided at the beginning of the test.h file.
> 
> 
> Diffs
> -----
> 
>   /trunk/build_tools/cflags-devmode.xml 235408 
>   /trunk/include/asterisk/_private.h 235408 
>   /trunk/include/asterisk/test.h PRE-CREATION 
>   /trunk/main/asterisk.c 235408 
>   /trunk/main/test.c PRE-CREATION 
>   /trunk/tests/test_heap.c 235408 
> 
> Diff: https://reviewboard.asterisk.org/r/447/diff
> 
> 
> Testing
> -------
> 
> test_heap.c has been modified to take advantage of the Test Framework.  I have executed and generated reports for these tests. 
> 
> 
> Thanks,
> 
> David
> 
>