On 1/11/19 11:12 AM, Peter Dimov via Boost wrote:
Robert Ramey wrote:
On 1/11/19 10:25 AM, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
One thing is true, though. Develop allows other libraries to be tested >> with your change.
Precisely.
It also allows provisional changes in other libraries to affect one's own test results. This can lead to huge wastes of time trying to find the source of bugs that were "secretly" inserted into your library.
If you don't do integration testing on develop, you'll do it on master, at a higher cost, when the "provisional" changes land there.
Or, as they say, if you don't have a test server, you do have a test server, you just call it "production".
It's not that I'm against doing the "integration testing" at all. I recognize that this needs to be done from time to time - presumably soon before a new release is shipped. But if the "next" version of each library is tested against the master, integration testing errors should almost never occur. But of course theory depends on assumptions that are not strictly true (e.g. stable interfaces) so "integration testing" is still required. The problem is that when it is done continuously, transitory errors can be tripped in dependent libraries. Since the dependent libraries presume that the other libraries being used are correct, they don't really check for errors - they just fail to perform correctly and soldier on. The requires that the working library be investigated to discover the source of a flaw which originates outside the library one is working on and testing. It can take a huge amount of time to track this down. Worse, the offending library isn't notified of the problem the author is created and time is lost. Robert Ramey