run-tests.py refactor

Idan Kamara idankk86 at gmail.com
Fri Apr 25 04:27:45 CDT 2014


On Fri, Apr 25, 2014 at 9:44 AM, Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 04/24/2014 08:03 PM, Gregory Szorc wrote:
>
>> On 4/24/2014 7:08 PM, Pierre-Yves David wrote:
>>
>>>
>>>
>>> On 04/24/2014 02:42 PM, Gregory Szorc wrote:
>>>
>>>> I'm working on a significant refactor of run-tests.py. My work can be
>>>> found in the indygreg/run-tests-refactor bookmark of
>>>> https://bitbucket.org/indygreg/hg. I plan to send the patches to this
>>>> list once the 3.0 window is behind us. But I wanted to give people a
>>>> heads up in case there are comments before the patch bombing.
>>>>
>>>
>>> Nice to see people showing interest in the test suite!. Are you aware
>>> that Anurag Goel will spend his Gsoc working on it? You guys should
>>> probably talk and synchronize.
>>>
>>
>> I wasn't aware of it until a few days ago, when I was neck deep in my
>> patch series. I assumed everyone is on this list. Part of the reason I
>> sent this email today was because I didn't want to jeopardize the GSoC
>> project and figured getting this patch series resolved and landed sooner
>> would be best for everyone.
>>
>
> Good move, having you working on the same area than a Gsoc student seem a
> win as you can probably collaborate on it.
>
>
>
>>  Cool, where you able to cleanly preserve the parallel run ability?
>>>
>>
>> Of course! I have a custom unittest.TestSuite class whose run() does the
>> multithreaded foo.
>>
>
> Multithreading? So each TestCase is pawning a new process running the
> actual test on the *.t file and and wait for it to return?
>
>
>  The execution time of the Mercurial tests is a common complaint. I did
>>>> some profiling and determined that the tests were spending an awful lot
>>>> of time in overhead of invoking the "hg" process. By executing tests in
>>>> shells, we have to incur the process start-up and repository
>>>> "re-association" costs for every invocation of "hg." The overhead is
>>>> significant.
>>>>
>>>> I added an experimental "pysh" mode that parses shell commands into
>>>> Python functions. If a .t file consists of only shell commands that can
>>>> be inlined to Python, the test executes in pure Python. For "hg" calls,
>>>> it creates a new mercurial.dispatch.request and calls
>>>> mercurial.dispatch.dispatch().
>>>>
>>>
>>> Note that we could also use the command server + chg for that. This
>>> would have the cool effect to test the commands server too. Have you
>>> tried in path?
>>>
>>
>> I had considered installing a fake `hg` into the test shell which talked
>> to a command server. But I haven't implemented it yet.
>>
>
> There is a version of such fake client written in C. It's called chg. I
> know that at least sean farley have been playing with it.


Indeed, and it does run some of the tests a lot faster:

https://bitbucket.org/yuja/chg/wiki/HgTestPerformance

But it can't really replace vanilla 'hg' for running tests, there are too
many
things that might behave differently.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20140425/83c1686c/attachment.html>


More information about the Mercurial-devel mailing list