Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
I am having a memory leak when running a test suite due to singleton objects are created and not cleared after each test case. And these singleton objects are holding references to heavy objects.
So I don't know if there is a better solution than clearing the singleton objects in the tearDown() methods in each test class!
What do you think?
typically, this means the singleton has outgrown its original intention, and should be made a standard object (read: not a singleton).
testability is one major reason. pains updating programs to use multiple instances are another. yet another: it's often a difficult bottleneck at execution. the singleton pattern is often overused, used for the wrong reasons, and leads to issues (like this).
so, you typically just make the object not function as a singleton anymore, or abstract its true shared exclusive data (if any) behind the interface of some class. this shared data and init/destroy sequence indicates that it is a singleton for the wrong reasons, or has grown to provide too much functionality.
as far as heavy objects: you can create initializers/constructors to support this use: ObjectWithMovie(movie)
if you absolutely need (often for historic reasons, unless your team continues to write singletons) a big blob of global mutable state (which is the current sum of your program's singletons and other global state), i prefer to make one class to hold these -- then the holder is the only singleton and responsible for initialization/destruction. then the complexity of your global shared state becomes more obvious (coincidentally, the reason many people don't like doing this).
anyways, the singleton is tough to test and from what i have seen, most uses have been made singletons for no good reason -- this is just becomes a pain when you need to test, reuse, extend, et cetera.
then you can happily execute all your tests (in parallel) without elaborate start up/tear down sequences.
good luck
So I don't know if there is a better solution than clearing the singleton objects in the tearDown() methods in each test class!!
Get rid of the singletons. Singletons are hard to test anyway (global state). Use dependency injection instead. Mock heavy objects with lightweight ones if you're still in trouble.
If you really can't get rid of those singletons, then try to "clear" them after each test. The "clear" needn't necessarily be in the tearDown() method, although it's a good place for such tasks.
Remove the Singletons. Then your problem is solved.
