Le 07/09/2021 à 10:52, ylavic@apache.org a écrit :
> Author: ylavic
> Date: Tue Sep 7 08:52:23 2021
> New Revision: 1893011
>
> URL: http://svn.apache.org/viewvc?rev=1893011&view=rev
> Log:
> test/time-sem.c: unlock the accept mutex before exiting (error conditions).
>
> Modified:
> httpd/httpd/trunk/test/time-sem.c
Hi,
just for my understanding, does anyone use these tests?
Are they run on travis? If no, should they be?
Same question, concerning the unitest framework (httpdunit)?
This is a great idea, but it looks mostly unused.
It tried to play with it a few years ago and found it quite hard to use,
because most of our functions need some "context" (i.e. a request, a
pool, a config, ...)
I was wondering if implementing such unittest as a module would make sense?
We could plug nearly anywhere with some hooks to have a meaningful
context. We could also implement a new hook to let modules implement
tests for functions that are not exported.
All this done, it could be run from our perl test framework as any other
module.
CJ
> Author: ylavic
> Date: Tue Sep 7 08:52:23 2021
> New Revision: 1893011
>
> URL: http://svn.apache.org/viewvc?rev=1893011&view=rev
> Log:
> test/time-sem.c: unlock the accept mutex before exiting (error conditions).
>
> Modified:
> httpd/httpd/trunk/test/time-sem.c
Hi,
just for my understanding, does anyone use these tests?
Are they run on travis? If no, should they be?
Same question, concerning the unitest framework (httpdunit)?
This is a great idea, but it looks mostly unused.
It tried to play with it a few years ago and found it quite hard to use,
because most of our functions need some "context" (i.e. a request, a
pool, a config, ...)
I was wondering if implementing such unittest as a module would make sense?
We could plug nearly anywhere with some hooks to have a meaningful
context. We could also implement a new hook to let modules implement
tests for functions that are not exported.
All this done, it could be run from our perl test framework as any other
module.
CJ