Hi! On 2013-05-08, Nicolas M. Thiery <nicolas.thi...@u-psud.fr> wrote: > I just made some tests (see attached file). Clearly Python uses > introspection.
In spkg-check of my group cohomology spkg, I use the following basic approach, also relying on introspection: 1. Start with a list of items (initially: The modules of the spkg) to be tested. 2. For each item O on the list: See if sage_getdoc(O) contains a doctest. If not or if the name of O does not seem to appear: complain (so, testing the coverage is part of the test suite). If yes: Execute it and complain according to the result. 3. For each item O on the list: Search dir(O) for classes, functions, methods, modules etc. Append these to the list, and recurse. Of course, dir(O) might contain stuff that is defined elsewhere, and thus, beyond the basic approach, one should do something to avoid executing the same test twice. The advantage of this approach: It does not rely on parsing source code. - It has been stated in the thread that indentation and stuff may confuse the current doctesting framework---this won't be an issue in my spkg. - It has also been stated in the thread that sometimes the name of the to-be-tested method can't be correctly determined---this won't be an issue in my spkg either. The disadvantage of this approach: It will only test stuff that can be imported by Python---cdef methods do not appear in dir(O). I don't know enough about Sage's new test framework to know if this approach would be a useful addition. Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
