It checks that objects allocated at the C++ level don’t leak memory. The python reference count will remove the top level object, but that’s not enough.
However, our extensive use of smart pointers (mostly shared_ptr, but we should be moving to unique_ptr) have meant that we have had very little trouble with C++ level leaks, so I can see why this appears unnecessary.
I realise that ticket’s out to me for review, so perhaps I should comment on JIRA or GitHub. But anyway, my first thought is – a bit more detail would be nice. For example:
Should one always use MemoryTestCase, or only when you’re explicitly importing Swigged C++? The example doesn’t seem to have any C++ in it all.
How does one use it properly? My experience has been that we end up with tearDown methods with a whole bunch of dels in them just to keep MemoryTestCase happy. Is that the intention? Is there a rule of thumb for what you actually need to delete vs leaving for the garbage collector?
How does it actually work, anyway?
(The last point there is going beyond what DM-5156 rather narrowly asked for.)
I don’t disagree with that – I believe it was assigned to you (@jsick) because the component was set to “Stack Documentation and UX”, rather than because you were carefully chosen as the most appropriate person to document it.
That said, what you’ve written is a vast improvement over the complete lack of information that we had before, so I’m inclined to say we should still go ahead and merge it. But that’s a discussion for JIRA…