Thanks Ronny. I will wrap the C/Fortran in python, name it test_* and expect it to work. I figured if I went that far it would work, since it amounts to just using py.test the normal way on tests that happen to use C library functions to do some work.
I had hoped that python namespaces were being searched for test_* rather than files. What you suggest about utility function makes sense, and it is my first choice. There is a subtle difference between the more intuitive thing you are suggesting: 1. Code to be tested is in fortran/C, tests are entirely in python, testing system is py.test and the precise thing I was asking about: 2. Code is in fortran/C, test is in fortran/C (with a helper macro to make it look easy) and the testing system is py.test That the latter can even be achieved is probably not obvious, but tools such as f2py have a callback system and I can write a little preprocessor macro for wrapping the test so that it looks like it is native but utilizes a python callback function for the assert (which will be a somewhat special one having to do with mpi). So it isn't that hard to achieve a unit testing framework that looks like it is written entirely in the native languages and has a fairly uniform way of treating parallel asserts (ie, it peforms the all-reduce so that the processors agree on pass/fail). But possible does not mean well-motivated. I am not sure that approach #2 is best even for my requirements, and it certainly would not be the best practice in general. It was more attractive if test collection would become trivially automatic rather than having to generate a test_* function to shadow each native test. Maybe I could write a custom collection hook to do that, but I don't want to bother anyone further until I run through my requirements and confirm this convoluted approach is actually better at meeting them. Thanks, Eli ________________________________________ From: Ronny Pfannschmidt [ronny.pfannschm...@gmx.de] Sent: Thursday, January 26, 2012 11:54 PM To: Ateljevich, Eli Cc: py-dev@codespeak.net Subject: Re: [py-dev] Can py.test collect a test inside a shared library? Hi Eli, by default py.test searches for test functions test_*.py as for test functions, they are supposed to start with test as well it might make sense to slit your c written test function into a few test util function, that way you can run the c written part step by step, and do assertions in between (for getting a more detailed idea of whats wrong, if something goes wrong) -- Ronny On 01/27/2012 06:16 AM, Ateljevich, Eli wrote: > Hi all, > If I have a test compiled from C or f2py that is called test_something and is > compiled to mymod.so (using Linux as the example), would it get collected ... > if you grant for the sake of conversation that I could possibly have > something useful to put in it? I realize I can't use the usual recompiling of > assertion magic. > > I tried creating an __init__.py file: > from mymod import * > > and running py.test on the directory without success. Maybe it needs to be in > test_something.py? I thought I would check in about whether this is credited > with a chance before I double my efforts. > > Thanks, > Eli > _______________________________________________ > py-dev mailing list > py-dev@codespeak.net > http://codespeak.net/mailman/listinfo/py-dev _______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
