|
|
Boost Testing : |
From: Robert Ramey (ramey_at_[hidden])
Date: 2007-05-07 01:36:55
Sorry I accidently end the previous post.
Robert Ramey wrote:
> Gennadiy Rozental wrote:
>> "Robert Ramey" <ramey_at_[hidden]> wrote in message
>> news:f1gnvf$bv8$1_at_sea.gmane.org...
>>> Gennadiy Rozental wrote:
>>>> "Robert Ramey" <ramey_at_[hidden]> wrote in message
>>>> This doesn't address neither testing against new version of your
>>>> library by developers of other libraies
>>>
>>> Sure it does - they can either test against the HEAD as they do now
>>> or they update their local installation
>>
>> Who is going to do this? Regression testers?
I was responding to the statement "
>>>> This doesn't address neither testing against new version of your
>>>> library by developers of other libraies
Developers can test which every they want. Regression testers
can test whatever they want. I presume they would
want to continue testing the HEAD. This doesn't help me
much but if some finds it useful to some purpose, it's fine
by me.
>> I am not sure how your reply relates to my comment. What I meant is:
>> How can YOU test that your library works with the next version of
>> let's say Boost.Test I am planning to include into next release.
Ahhh - now that is the question. This can only fail if the next version
of Boost.Test has a different interface than the previous version. If
if the interface changes then a test failure would be an error in
boost test which is beyond my scope, expertise and authority to
address. So there is no point in my testing for it. If the
author of Boost Test wants to use the serialization library
to test his new version - of course he's free to do so.
If a library that I depend upon changes its interface and/or support
too frequently, I'll have to decide on case by case basis
whether using the library is more trouble than it's worth.
In any case, It seems current regression testing isn't going
to change much in the near future so I would expect these
kinds of errors will continue to be caught by the current system.
>>> I think boost as a concept has to change from tightly
>>> coupled group of "standard" libraries to a loosely
>>> coupled group of "interoperable" libraries. At its core
>>> I think this is the issue. Good news is that its not something
>>> that we have to agree upon. Its happening now as it
>>> must as boost get beyond the scale where it can be
>>> digested as a whole.
>>
>> This comment I completely agree with. I just porpose how add some
>> formalization to this process.
Hmm - my "formalization" is to discourage libaries from
changing their interface and/or support very often.
Robert Ramey