stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <>
Subject Re: num_get thread safety tests
Date Sat, 04 Aug 2007 00:11:36 GMT
Travis Vitek wrote:
>> Martin Sebor wrote:
>> I suppose that would be okay just so long as it's possible to still
>> exercise one facet without the other. Which I suspect might defeat
>> your goal of integrating the testing of both facets into the same
>> program.
>> The problem with creating a dependency between the two facets is
>> that a bug in one might prevent the other from ever being tested
>> or might cause false positives in the other, making debugging the
>> problem more difficult. At the same time, exercising both of the
>> facets simultaneously would be valuable in its own right so it
>> would be nice to be able to do both.
> Okay, I think I'm going to settle for having separate tests for the get
> and put. I believe this is what you had originally intended, and I hope
> that is still acceptable.

It's definitely the easier of the two approaches and I agree
it's the way to go if you don't want to get bogged down in
fixing the process API in the test driver. We will need to
fix it at some point but now is not the time.

>> An idea that would let us have it both ways is to integrate the
>> tests for both (all three when you count numpunct) facets into
>> the same program, still keeping the option of running them
>> independently of one another, exercising them all at the same
>> time by default and, when one fails, invoking the program again
>> and exercising them independently, one after another. This
>> approach would involve at least two processes: one to drive and
>> monitor the tests, and another one or more running the tests
>> themselves. The infrastructure for this approach has already been
>> put in place: see the rw_process_create() API in the test driver.
>> Unfortunately, the tests for the API have been failing on a number
>> of platforms so there are issues with it that remain to be resolved.
> That is more trouble than I'm wanting to chew on at this time. This
> seems rather complicated, and since I'm not yet familiar with how the
> testing infrastructure works, I'm worried that I would end up spending
> time trying to get this approach to work and not writing tests.



View raw message