>> - 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.
The Cython serializer (is at 50% though) can easily go
somewhere else (Cython/Compiler/? Or Cython/?); but it should stay a
seperate file. 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...)
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?)
> No, not a good idea. Add a test class to the runtests.py that only
> transforms the code, and then provide each test file with the expected
> result in a string, just like the error tester does. That way, you can
> still add a doctest to the source file and run the unchanged code and the
> transformed code through the normal test runner to see if both work as
> expected.
>
> Something like this might work as a test layout:
>
<snip>
> And then you parse the source file (see the error test class for this) and
> append a serialisation of a dictionary that maps the names of all Python
> functions found in the file to their transformed body, before you compile
> and run the file in the test runner. Do you think that would work?
I can sympathize with the goals, but it needs some changes.
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.)
I.e there must be a mechanism for specifying exactly which transforms to
run.
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")
- 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.
So, in conclusion, perhaps I could fill testing/transforms with
xml-files like this?:
<?xml version="1.0" encoding="utf-8"?>
<test stage="coerced" transform="ForInOptimizations">
<pxd name="test">
cdef class A:
cdef int i
</pxd>
<pyx>
cimport test
cdef A a
</pyx>
<expected>
cimport test
cdef A a
</expected>
</test>
(I'll implement that nice and cleanly BTW, have the parser read StringIO
objects from strings in the DOM...)
BTW, the output is not always going to stay valid Cython, but I can just
not add doctests for those...
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?
--
Dag Sverre
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
