Hi,
maybe it's even simpler than I proposed, you could just pass the dictionary
into the doctest environment (somehow ;) instead of modifying the source file.
Dag Sverre Seljebotn wrote:
>>> - Have a Cython/Testing directory for the test utils...
>> Are the test utilities so large that you really need a new source file or
>> even an entire package? And, since you have a Python serialiser in place -
>> do you really think that belongs into a test package?
>
> The short answer to this is: Just tell me where to put it.
not sure, maybe "Cython/CodeWriter/CythonCodeWriter.py" ?
> The potential uses outside of debugging and testing are a
> bit limited though (theoretically it could make a Cython source
> prettifier but then the parser must insert comment and whitespace nodes...)
or a plain Python serialiser (i.e. cdef remover).
> As for the test utils, wherever. Can I put it in "Cython/TestUtils.py",
> so that any more test utils can be added later?
>
> (Out of curiosity, does a package have more overhead than a few inodes
> on my filesystem? Or is it just that you don't like to have many of them?)
I was just trying to find out if it's too big to fit into the test runner, but
the stuff you mentioned makes it at least a module.
> Issues:
> - I don't want to test that the entire pipeline. I.e., if another
> transform comes along later it might do further optimizations to that
> loop which I do not want to interfer with the test. (This is all about
> the "brittle interdependency" stuff -- I don't want to care about what
> is happening elsewhere when I'm working on one part of the compiler.)
Then write a good test case. ;)
> I.e there must be a mechanism for specifying exactly which transforms to
> run.
the compilation options maybe?
> BTW, the reasons for these tests are to set up checkable contracts
> between different stages of the compilation, not to check that the
> end-result is working. For the end-result regular tests like what we
> have will also be needed. ("unit tests" vs. "integration tests")
Fine.
> - Transforms generally don't work on such a small level that they can be
> tested within function definitions. Closures will need full module-scope
> comparison, inlineable functions (NumPy __getitem__ ...) will need
> cross-cimport-tests. With a runtime syntax I could simply do
>
> test_transform(..., code="""
> cimport test
> ...
> """, pxds={"test": """
> cdef class A: ...
> """})
>
> and so on. It would be horrible to have to go make different files in
> order to test simple cross-import functionality.
Why? You'd have a couple of simple, reusable .pxd files that provide a single
thing and they would be used by multiple tests. That's how it works already.
> BTW, the output is not always going to stay valid Cython, but I can just
> not add doctests for those...
That's not a problem if you run the compiler completely.
> On a related note, this doesn't cover some other tests I might want to
> do that isn't related to straight input/output. Perhaps one could have
> "testing/pyunit" for PyUnit tests or similar?
If it's a "real" unit test, Cython/Compiler/Tests would be ok with me.
Stefan
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
