Craig Citro wrote: > Hi all, > > So I'm currently trying to write some tests for a subtle issue > involving resolving imports and cimports. (I think I emailed about > this a while back.) The particular issue isn't so important right this > minute -- the only thing that matters is that to test it, I need a > test with a few layers of directories, with __init__.py files > sprinkled in several places, and potentially *not* at the root. > Unfortunately, this doesn't work so well with the current testing > setup -- at least, as I understand, there's no way to tell it "when > you try to run this test, also copy along this particular chunk of the > current directory." So there are two obvious choices: > > 1) Give a test a way of specifying what other files should come along > as part of it. > 2) Create a directory called nested (or something else) somewhere in > the tests/ tree (maybe one for each of the current subdirectories?), > and add code to runtests.py to handle that whole tree at once. > > Each of these has its ups and downs -- but I'd love it if someone told > me that the testing code already did what I'm looking for, and I just > didn't know it. ;) I think (1) feels like the "classier" solution, but > (2) would make it easy for someone to *add* a nested test without > having to create a whole bunch of files/directories themselves. That > said, we'd have to be careful that no one accidentally broke a test by > modifying it -- tests really should be nearly immutable. > > Any thoughts? > If this ends up being coded from scratch, I think it would make testing easier if one could actually write down all the files in a single testcase bundle file (e.g. with a "test" suffix). Something like the following, which is simply split up into seperate files by runtests.py:
== mydir/__init__.py # This file is empty == mydir/foo.pyx cdef int x = 3 == mydir/foo.pxd cdef int x This is because such tests would tend to have a lot of very small files testing specific functionality, and it would be very tiring to browse around such trees and open all the files to see what is going on. Dag Sverre _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
