Hi Eli, i simply suggested, option 1, cause its much more easy and straightforward to do from my pov
its entirely possible to implement implement a collector that gets to participate in finding test functions inside of a shared library (just like osjekit does for javascript files for example), and if the shared lib acts close enough to a module, it may even be possible to reuse the Module collector but you will loose some of the python integration things if you do that and i'm not sure if its reasonably simple to bring those to a c/fortran binding -- Ronny On 01/27/2012 04:52 PM, Ateljevich, Eli wrote: > 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ py-dev mailing list py-dev@codespeak.net http://codespeak.net/mailman/listinfo/py-dev
