On 2017-08-06 22:40, David Anderson wrote:
Please read https://boinc.berkeley.edu/trac/wiki/SoftwareTesting
in particular the definition of "stable".
[...]
Testing a feature in isolation is not the same as testing the system.
Indeed.
But that doesn't mean that "testing in isolation" shouldn't happen, in
particular as you wrote on the wiki page: "we currently have no way of
testing server software [as a system (my addition)]". The server
software is indeed way too complex to be tested as a whole, thus one
should (at least) test the components ("isolated"). These are tests that
- unlike stated in the Wiki page - _can_ be done by developers (or by
continuous integration for them automatically). This might not catch all
problems, but more than enough, before exposing these to the projects
and the public.
Again: writing and performing the test that can be performed isolated
and automatically will actually save us (here: first and foremost the
projects, ultimately the developers, too) work, even if it looks like
more work (for the developer) at first.
No one is advocating committing untested or buggy code into master.
Ok - then how do you prevent this from happening if everything,
including unfinished and untested development, is committed into "master"?
However, feature testing doesn't mean that master is stable.
No, this is not sufficient, but nevertheless necessary and helps a lot.
IMO an unstable "master" or "trunk" is a no-go for distributed,
collaborative software development. Thus we should strive to stabilize
"master" as much as possible by writing tests that can be executed
automatically, and by peer-reviewing every change made to it. If we
can't agree on that, I'm afraid you are - and will continue to be - on
your own.
Bernd
_______________________________________________
boinc_dev mailing list
boinc_dev@ssl.berkeley.edu
https://lists.ssl.berkeley.edu/mailman/listinfo/boinc_dev
To unsubscribe, visit the above URL and
(near bottom of page) enter your email address.
