Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2004-02-16 12:49:38


At 09:26 AM 2/16/2004, David Abrahams wrote:
>Beman Dawes <bdawes_at_[hidden]> writes:
>
>> At 11:18 PM 2/12/2004, David Abrahams wrote:
>> >Beman Dawes <bdawes_at_[hidden]> writes:
>> >
>> >> >3. Compile time may become very large for large test
>> >> > programs or heavy template usage. E.g. in one case,
>> >> > we had to split a test into three (Spirit's switch_p
>> >> > tests) in order to make testing feasible.
>> >>
>> >> It is hard to know the overall effect without accurate timings. My
>> >> personal belief is that on average the total time will drop. But we
>> >> need timings to know for sure.
>> >
>> >I still can't understand why we're focused on reducing testing time.
>>
>> The longer the tests take, the fewer times they can be cycled.
>>
>> That is a particular problem as a release nears. The release manager
>> often has to delay some action pending the outcome of tests. Not a
>> problem if the tests run quickly and cycle often. But when a test
>> cycle takes 2 1/2 to 3 hours, as was common during the runup for
>> 1.31.0, it adds days to the time it takes to finish a release.
>
>But if we were only running the outdated tests, this would be much
>less of an issue, right?

Yes. Also note that we've talked about other changes which also will serve
to minimize compile and/or test times. Dropping outdated compilers.
Reworking tests which take excessive times. Etc. The combined effect could
be markedly reduced regression testing load.

--Beman


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk