Re: svn commit: r1893011 - /httpd/httpd/trunk/test/time-sem.c

2021-09-08 Thread ste...@eissing.org



> Am 07.09.2021 um 22:04 schrieb Christophe JAILLET 
> :
> 
> Le 07/09/2021 à 10:52, yla...@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=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.

Re: svn commit: r1893011 - /httpd/httpd/trunk/test/time-sem.c

2021-09-07 Thread Christophe JAILLET

Le 07/09/2021 à 10:52, yla...@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=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