Mailing List Archive

Re: svn commit: r1893011 - /httpd/httpd/trunk/test/time-sem.c
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
Re: svn commit: r1893011 - /httpd/httpd/trunk/test/time-sem.c [ In reply to ]
> Am 07.09.2021 um 22:04 schrieb Christophe JAILLET <christophe.jaillet@wanadoo.fr>:
>
> 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.

I had a quick look since in mod_h2 I have some unit tests that may get transferred too. But then other things occupied my time.

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

Hmm, that would be a neat way to solve the export restrictions. Build in maintainer mode only or some other define.