Daniel Russel wrote: > If it weren't for the memory corruption issue, we could > presumably just tell Python.unittest how many tests we expect to have > fail and have it modify the return state accordingly.
I don't believe you can do that, actually - at least, not without writing your own subclass to do it.
> At the very least, > such bugs should be stuck somewhere on the wiki (or the doxygen todo > list) rather than just working around the failure, but I would much > rather have a test failure.
Sure, but code that triggers a test failure should not be committed - or, at least, not unless it's going to be fixed within a day or two. Lab culture is to expect SVN to be usable "most of the time".
We already have Bugzilla set up for Modeller bug tracking. It would be trivial for me to add an IMP component if people had bugs to put in it.
> So where do I put C++ tests when I have written them?
There currently isn't anywhere, so you'd just send them to me. Then I have to figure out how to integrate them into the build system.
> I don't think we really want to have two separate test frameworks (or > rather, I don't think /you/ really want to have two separate test > frameworks :-)
Indeed. If people are going to using the functionality in Python, I'd much rather it were tested there, since there are many areas of the SWIG wrapping that can introduce problems (one example is the correct mapping of C++ operator overloads to the corresponding special Python methods - e.g. const operator[] to __getitem__ and non-const operator[] to __setitem__). C++ unittests probably only make sense for internal stuff (which seems to be largely covered by IMP_check and friends anyway) and things that are tough to check in Python, such as C++ reference counting.
Ben