testing hg using subprocess.Popen()

Chris Jerdonek chris.jerdonek at gmail.com
Thu Dec 26 19:08:26 CST 2013


On Thu, Dec 26, 2013 at 6:19 AM, Augie Fackler <raf at durin42.com> wrote:
>
> On Dec 23, 2013, at 9:42 PM, Chris Jerdonek <chris.jerdonek at gmail.com> wrote:
>
>> I have a need to write some tests that can check more than what
>> "unified tests" currently allow.  For example, I would like to use
>> Python to compare the stdout of `hg` against some
>> dynamically-evaluated Python expressions.  Also, some of the
>> substrings I would like to check vary across multiple lines which
>> isn't currently supported by the per-line "filtering" functionality
>> (glob, re, etc).
>>
>> So as not to add new test scripts, my idea was to convert an existing
>> unified test into a "pure unit test" (i.e. the kind of test mentioned
>> at the end of this section [2]), and then use subprocess.Popen() to
>> invoke `hg`.
>>
>> Does anyone have any thoughts on this?  I didn't find any examples
>> like this in the test suite.  It seems like a helper function to call
>> `hg` using subprocess.Popen() would be useful to have in the tests
>> folder.  However, I didn't come across any examples of helper test
>> functions being imported in any of the Python unit tests.
>
> Hm. I guess where I'd go for now would be to capture stdout/stderr in a file and then use inline Python in a .t file to make the assertions you need. Would that work as a stopgap?

It's possible it would, but I already wrote up that part of the patch,
so I think I'll stick with the pure unit test approach for the initial
review.

By the way, it turns out there is already an example of shared test
code that gets imported by some tests, namely the silenttestrunner.
So if we did want to share more code, we could always put more things
into that file.

--Chris



>
>>
>> For DRY purposes, etc, it seems like it would be useful to be able to
>> share code across Python unit tests.  Starting to do this might be
>> another way to chip away at the following problem mentioned in the
>> wiki: "The test suite is slow. And the test suite is slow because it
>> is highly redundant.." [1]
>>
>> I'm asking now because I wanted to hear people's thoughts before I
>> prepare my next patch.  Thanks.
>>
>> --Chris
>>
>> [1] http://mercurial.selenic.com/wiki/WritingTests#No_more_new_test_scripts.21
>> [2] http://mercurial.selenic.com/wiki/WritingTests#Writing_a_Python_unit_test
>> _______________________________________________
>> Mercurial-devel mailing list
>> Mercurial-devel at selenic.com
>> http://selenic.com/mailman/listinfo/mercurial-devel
>


More information about the Mercurial-devel mailing list