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<MyView>().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

Often memory leaks are introduced when managed types use unmanaged resources without due care.

A classic example of this is the System.Threading.Timer which takes a callback method as a parameter. Because the timer ultimately uses an unmanaged resource a new GC root is introduced which can only be released by calling the timer's Dispose method. In this case your type should also implement IDisposable otherwise this object can never be garbage collected (a leak).

You can write a unit test for this scenario by doing something similar to this:

var instance = new MyType();

// ...
// Use your instance in all the ways that
// may trigger creation of new GC roots
// ...

var weakRef = new WeakReference(instance);

instance.Dispose();
instance = null;

GC.Collect();
GC.WaitForPendingFinalizers();
GC.Collect();
Assert.IsFalse(weakRef.IsAlive);

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.)