One problem with fixing the refresh is that the more you fix, the longer the refresh will take. To fix Five to be stable in refresh, we may very well have to kill all things registered by ZCML, and re-register all of it. It's highly unlikely that we get a real stable refresh by just refreshing one products ZCML. What happens if there are overrides, and so on. So, in the end, you end up with refreshing everything, which would take just as long as stopping and starting the ZEO client. We can probably make it possible to make the refresh somewhat more stable and support a wider range of cases. But you still have to make very careful configuration of the refresh in most of this cases, and if you don't do it just right, it won't work. So I'm not sure it's worth the effort. Doing tests is a good idea especially if you take a bit of care. The calendar products I'm working on have that care taken automatically, as it's split into three products, one pure python, one Zope layer with the persistance and UI and one CPS integration. Most tests are on the python product, or the Zope product. The python tests take 0.8 seconds to run, the Zope tests 4 seconds. With CPS it gets worse, because the tests need to create a CPS site. It's the same with Plone. In those cases tests will not be faster than refreshing. Running all of them takes a bit less than a minute I think, and running just one isn't that much faster. But the amount of tests needed there is very low, as most is done on the CalCore and CalZope layer. This way development is pretty fast, and doesn't need much refreshing. Then comes a part where you need to get it to actually work, and not just pass the tests. Here you need to refresh a bit. And then most of the work is UI-fixing, which doesn't need refresh again, because it's mostly HTML. I find this mode of development faster than when I had working refresh, beause the existance of the tests stop me from shooting my foot. ;)