[PATCH 1 of 3] debuginstall: convert unified test to pure unit test (issue4128)

Matt Mackall mpm at selenic.com
Mon Dec 30 19:09:30 CST 2013


On Mon, 2013-12-30 at 16:34 -0800, Chris Jerdonek wrote:
> On Mon, Dec 30, 2013 at 3:30 PM, Matt Mackall <mpm at selenic.com> wrote:
> > On Fri, 2013-12-27 at 17:20 -0800, Chris Jerdonek wrote:
> >> # HG changeset patch
> >> # User Chris Jerdonek <chris.jerdonek at gmail.com>
> >> # Date 1388190507 28800
> >> #      Fri Dec 27 16:28:27 2013 -0800
> >> # Node ID 3a91ff8b2a83bcfbad000f0140c9df67b0022522
> >> # Parent  4274eda143cb1025be1130ffdaaf62370a2a6961
> >> debuginstall: convert unified test to pure unit test (issue4128)
> >>
> >> This change converts the test file for debuginstall from a unified test to
> >> a pure unit test.  This gives us more flexibility in testing the output
> >> of "hg debuginstall".  In particular, this will let us test in a
> >> straightforward way the changes to debuginstall for issue4128.  For example,
> >> the change lets us use Python to calculate the expected value of substrings
> >> of the output, and then compare them.
> >
> > Going from .t to .py with custom code to do line matching is two steps
> > backward, one step forward. I'd much rather you added optional line
> > support in .t output so the next person who needs this feature doesn't
> > have to rewrite their test in the bigger, harder-to-maintain .py test
> > style.
> >
> > But I really don't see the reason to do this at all for this bug.
> 
> The other testing feature I needed for this issue is the ability to
> compute the expected value of a substring of the test output.
> 
> For example, another part of issue 4128 is to show "information about
> the Python that Mercurial was compiled against."  So I would like
> debuginstall to display something like the following for one of its
> output lines--
> 
>   using C extensions (yes)...
> or
>   using C extensions (no)...
> 
> In a .py file I can compute whether that should be "yes" or "no."  Can
> that be done using a .t file?

Yes, using conditionals. There is not yet a conditional for pure as
there's been no call for it to date. But use a wildcard and call it
done, please. At the end of the day, it's just debugging output.

>   Any suggestions?  Another complication
> is that it might make sense to show additional lines of output if the
> answer is "yes."  Testing with a .py file doesn't impose constraints
> on the form of the output.

It sure doesn't. Instead it imposes overhead on maintenance and
comprehension. Which is why there are so few .py tests and why I'm
pushing back on this. 

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list