<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>Why? All that is needed is to be able to run the same tests on all fork.</div></blockquote><br></div><div><div>So when magma - written in squeak, requires one variant with complex facilities such as remote invocation of images, and Seaside written in pharo requires another. The integrator who wishes to test both in one image may find irreconcilable differences. Not all testing code uses the lowest common denominator.</div><div><br></div></div><div>So what will happen is the multiple variants of SUnit will exist in a creative tension, to the extent that evolving any of them will become virtually impossible.</div><div><br></div><div>A trivial example, I prefer that shouldInheritSelectors be specified explicitly, most implementations set it automatically for Abstract classes. An "improvement" as simple as this will never happen. Another trivial example, there are no users of LongTestCase in the squeak image, having a general test categorisation mechanism will provide the same facility. Write one test case that required LongTestCase, and you force me to remain compatible.</div><div><br></div><div>What is so wrong with treating SUnit as a loadable package with maintainers and conversations to discuss its future, so that it may actually evolve. You seem to think it is a bad thing.</div><div><br></div><div>Keith</div><div><br></div><div>p.s. I think Cuis will be great for squeak, because...</div><div><br></div><div>1. as long as it loads in Cuis, it will load in most places.</div><div>2. The Cuis version are like to be simpler than others</div></body></html>