unit testing memory leaks

Question

I have an application in which a lot of memory leaks are present. For example if a open a view and close it 10 times my memory consumption rises becauses the views are not completely cleaned up. These are my memory leaks. From a testdriven perspective i would like to write a test proving my leaks and (after I fixed the leak) asserting I fixed it. That way my code won't be broken later on. So in short:

Is there a way to Assert that my code is not leaking memory from a unit test?

e.g. Can i do something like this:

objectsThatShouldNotBeThereCount = MemAssertion.GetObjects().Count; Assert.AreEqual(0,objectsThatShouldNotBeThereCount);

I am not interested in profiling. I use Ants profiler (which I like a lot) but would also like to write tests to make sure the 'leaks' don't come back

I am using C# / Nunit but am interesed in anyone having a philosophy on this...

Answer 1

You don't need unit tests you need memory profiler. You can start with CLR Profiler.

Answer 2

That memory consumption increases is not necessarily an indication of a resource leak, since garbage collection is non deterministic and may not have kicked in yet. Even though you "let go" of objects, the CLR is free to keep them around as long as it deems enough resources are available on the system.

If you know you do in fact have a resource leak, you may work with objects that have explicit Close/Dispose as part of their contract (meant for "using ..." constructs). In that case, if you have control over the types, you can flag disposal on the objects from their Dispose implementation, to verify that they have in fact been disposed, if you can live with lifecycle management leaking into the type's interface.

If you do the latter, it is possible to unit test that contractual disposal takes place. I've done that on some occasions, using an application specific equivalent to IDisposable (extending that interface), adding the option for querying whether the object has been disposed. If you implement that interface explicitly on your type, it won't pollute its interface as much.

If you have no control over the types in question, a memory profiler, as suggested elsewhere, is the tool you need. (For instance dotTrace from Jetbrains.)

Answer 3

You might be able to hook into the profiling API but it looks like you would have to start your unit tests up with profiler enabled.

How are the objects being created? Directly or some way that can be controlled. If controllable return extended versions with finalizers which register that they have been disposed. Then

GC.Collect();
GC.WaitForPendingFinalizers();
Assert.IsTrue(HasAllOfTypeXBeenFinalized());