Hi, The point I'm trying to make is that even on an alpha release, everything that worked before should still work perfectly. The new stuff being added are first buggy; seems normal to me. But if the new stuff is breaking old, working stuff, and we only notice it after a month; then it will take us a lot of time, debugging the issues, investigating them; time we should spent instead on adding new stuff.
The feeling I have is that most of the code is unit tested, which is fine; but that little code is integration tested. The bug I described above is a misconfiguration between some packages, and since the environment itself are also just packages, there should be some integration test to test the pharoxxx.dev.image to see if everything is integrating correctly with each other. I mean a testcase which just opens a browser and 'clicks' on all items to see if everything is still working. On my day to day work I firmly believe in taking small steps, making sure that these small steps don't break anything. And if there is a test failing then, taking that small step; i immediately get the feedback that my small change has influence on some other part of the system, which I did not see before. Every bug we find is first reproduced by writing a failing test for it. Like this we are sure we fix the right thing, and furthermore we are sure that this bug will never reoccur again. We used to have someone on the team who got furious if only one file was committed during a change which added behaviour. She was right: every change should have a corresponding test. Again about the bug I posted. How would this issue be fixed? How can I fix this? I can in the O2classes / test create a 'mock' description which knows the packages instead of the package message. And then fix it then, that seems to be step one. However I did not actually reproduce the bug, since the bug was: I click in a System browser, and call browse package, which failed. It is that kind of test I want to write for it. Since the tools are part of the environment, they should be integration tested. I will make an attempt to write such a test. |The Smalltalk "tradition" slightly differs here, as the more tolerant |developers use the alpha build, but people doing production work use the |latest stable release (in this case 1.0). |I've done a number of production applications in Squeak and we always |used the stable version for that. Or, in case we really needed something |from the trunk version, we only updated occasionally when we were sure |it had reached a somewhat stable plateau. You're correct on this one, however in this case, Pharo IS the production work. It is Pharo itself we are also developing. And since it is development, I think we should make sure the quality keeps up at a highest level possible, even if modifying it. I don't mean to criticize, I love the opensource initiative that Pharo is, I'm just trying to help Pharo further. Any other thoughts on this? Kind Regards, Bart
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
