[PATCH 1 of 5] run-tests: when building json, use result.failures instead of result.faildata

Gregory Szorc gregory.szorc at gmail.com
Sat May 9 11:37:44 CDT 2015


On Fri, May 8, 2015 at 5:01 PM, Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 05/08/2015 04:30 PM, Gregory Szorc wrote:
>
>> On Fri, May 8, 2015 at 11:53 AM, Pierre-Yves David
>> <pierre-yves.david at ens-lyon.org <mailto:pierre-yves.david at ens-lyon.org>>
>> wrote:
>>
>>     # HG changeset patch
>>     # User Pierre-Yves David <pierre-yves.david at fb.com
>>     <mailto:pierre-yves.david at fb.com>>
>>     # Date 1431066024 25200
>>     #      Thu May 07 23:20:24 2015 -0700
>>     # Node ID dccc3de8c055f386a1dbfe72e86091251dbd0b50
>>     # Parent  c25b2adb3664cd3c488e2c53aab0c64100d40af7
>>     run-tests: when building json, use result.failures instead of
>>     result.faildata
>>
>>
>> If you are going to spend a lot of time on run-tests.py, I suggest you
>> wait a few days for Python 2.4/2.5 to be deprecated. There is tons of
>> legacy/polyfill code in run-tests.py that exists solely to support
>> antiquated versions of the unittest package. The file should become much
>> simpler once it is refactored to use modern unittest primitives.
>>
>
> I'm pretty much done spending time in it. the second part of this series
> add recording of start and end of each test. And helped me speeding him my
> test run.
>
> Does dropping 2.4/2.5 changes this failures/faildata things?


IIRC the modern unittest API offers better mechanisms for dealing with
reporting of test results.

Also, our current implementation of result reporting that writes output,
obtains a lock, etc grossly violates the intended unittest API. Cleaning it
up is very far down on my priorities list, however.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://selenic.com/pipermail/mercurial-devel/attachments/20150509/9904613f/attachment.html>


More information about the Mercurial-devel mailing list