On Wednesday 10 January 2018 at 04:07 pm +0700, Duy Nguyen wrote: > On Mon, Jan 08, 2018 at 01:25:04PM +0100, Johannes Schindelin wrote: > > I agree that it would make a ton of sense to use a proper, portable test > > framework written in pure, portable C. > > > > However, this ship has long sailed, hasn't it? > > If you meant converting the whole test suite, oh yeah that's not gonna > happen. But it's still possible to have some tests written in C. > > I played a bit with this. The assumption is if it's agreed that we can > get something bare bone (but functional) in then we could start having > more and more C-based unit tests in future and also improve the C > framework to be on par with shell one on the side. > > There are still some minor problems with my patch, and a bunch of > optional features not supported. But the numbers looks unexpectedly > promising. 0.7 seconds on the shell version and 0.03 on the C one. I see even more promising results from a single run on one of my Cygwin systems: from 21.3 seconds for t3070 to 0.112 seconds for your t3071. I expect there's a similar improvement in Dscho's Git for Windows environment. > One disadvantage of this though, if this kind of framework does not > get popular, then any new test feature must be added at both places > but it's a waste of time to support both. So... I don't follow: if we end up implementing every test twice, as we have here, then I agree, but I don't think there's much value in doing that except as a proof of concept, as in this immediate discussion. The obvious-to-me way to do this would be following the precedent of the core code: gradually migrate things away from shell code to C code. Adam
