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.

Reply via email to