Re: Future development

On 10/07/07 20:55, David Abrahams wrote:
> on Sun Oct 07 2007, Larry Evans
<cppljevans-AT-cox-internet.com> wrote:
> 
>> On 10/06/07 19:08, Douglas Gregor wrote:
>> [snip]
>>> Okay. One could certainly make the executables
for some tests  
>>> dependent on the executables of other tests, so
if the type_traits  
>>> tests fail to build then one doesn't build the
tests for other  
>>> libraries that depend on type_traits.
>>>
>>> I don't think we could make chain tests based
on whether a test  
>>> *executes* correctly.
>>>
>> redflag!
> 
> I'm not alarmed.  It means some tests may attempt to
run needlessly,
> but we'll still get all the results we need.

True, but then you wouldn't know whether the higher level
test
failed because of a bug in the higher level code or a bug
in
the lower level code.  The higher level test only says
something
like "I've failed test XXX" it doesn't say "I
can't run test XXX
because test YYY failed".  So, instead of first
debugging
lower level test YYY, XXX's author would start searching for
a
"false" bug in XXX. THat wastes time.

[snip]

> I'm not aware of any Boost library that actually
creates such
> dependencies among its tests, are you?

I know of no such tests.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

On 10/08/07 05:10, Larry Evans wrote:
> On 10/07/07 20:55, David Abrahams wrote:
>> on Sun Oct 07 2007, Larry Evans
<cppljevans-AT-cox-internet.com> wrote:
[snip]
>>> redflag!
>> I'm not alarmed.  It means some tests may attempt
to run needlessly,
>> but we'll still get all the results we need.
> 
> True, but then you wouldn't know whether the higher
level test
> failed because of a bug in the higher level code or a
bug in
> the lower level code.  The higher level test only says
something
> like "I've failed test XXX" it doesn't say
"I can't run test XXX
> because test YYY failed".  So, instead of first
debugging
> lower level test YYY, XXX's author would start
searching for a
> "false" bug in XXX. THat wastes time.

OOPS.  I guess if YYY failed, XXX's author would realize
XXX
depends on YYY and ignore the failure of XXX until YYY
passed.

Sorry for noise.

[snip]

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Larry Evans wrote:
> On 10/07/07 20:55, David Abrahams wrote:
>> I'm not aware of any Boost library that actually
creates such
>> dependencies among its tests, are you?
> 
> I know of no such tests.

Whilst not in Boost, I do a lot of tests that require
specific
hardware be present in a machine, not actually running
functional
tests on machines that do not have the hardware is quite
useful.

I say functional tests because I obviously use a mock/stub
for the
unit tests where possible. The alternative for me is to
repeat the
hardware detection across a range of tests, this gets harder
to
implement as I do larger integration/functional tests.

In these cases its nice to be able to say the opposite too,
'Run this
test if the previous one failed' for instance to test fail
over type
tests.

Kevin
-- 
| Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this
     |
| Senior Technology                     | My employer for
certain |
| And Network Systems Architect         | Not even myself   
     |
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build

Larry Evans wrote:
> On 10/07/07 20:55, David Abrahams wrote:
>> I'm not aware of any Boost library that actually
creates such
>> dependencies among its tests, are you?
> 
> I know of no such tests.

Whilst not in Boost, I do a lot of tests that require
specific
hardware be present in a machine, not actually running
functional
tests on machines that do not have the hardware is quite
useful.

I say functional tests because I obviously use a mock/stub
for the
unit tests where possible. The alternative for me is to
repeat the
hardware detection across a range of tests, this gets harder
to
implement as I do larger integration/functional tests.

In these cases its nice to be able to say the opposite too,
'Run this
test if the previous one failed' for instance to test fail
over type
tests.

Kevin
-- 
| Kevin Wheatley, Cinesite (Europe) Ltd | Nobody thinks this
     |
| Senior Technology                     | My employer for
certain |
| And Network Systems Architect         | Not even myself   
     |

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost-build