This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Writing tests using Python


On 06/26/2017 07:38 AM, Joseph Myers wrote:
> We currently have pretty-printers tests and benchmarks using Python.  
> Would people consider it reasonable to have other tests using Python 
> (appropriately conditioned in the Makefiles, of course)?  (Specifically, 
> I'm thinking of writing more thorough tgmath.h tests using a Python script 
> to generate the C tests, with the output not being checked in, with a view 
> to then adding _Float128 support to the generator when adding it to 
> tgmath.h.  Let's assume version requirements are no stricter than those 
> documented for the pretty-printers tests, so the code works with both 
> Python 2 and 3.)
 
I have no objection to using more Python to generate the tests.

We use quite a bit of python already in the Unicode regeneration process
and that's similar.

The pretty-printers are a very special use-case, requiring expect, gdb,
and all of that was simpler using python. If you need to debug the
pretty-printer then you can do so using gdb, the printer, and another gdb.
There is no need to directly debug the PExpect-based test (except when that's
the only thing that's failing).

Where I would get worried would be if we had more complex tests driven in python,
and debugging that python to try debug the C test would be adding a variable
to an already complex low-level debugging scenario. In your case with tgmath.h
you can easily debug the resulting C test with gdb to determine what is going
wrong so that's not a problem.

-- 
Cheers,
Carlos.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]