I am interested in what kind of unit test fixtures people are using with JUCE. Currently my tests do nothing in terms of fixture, and they run fine, but they inevitably trigger the LeakDetector on shutdown. For example, testing a Component leaves me with:
*** Leaked objects detected: 1 instance(s) of class OSXTypeface
What do you do to properly setUp and tearDown the JUCE? Thanks.
There are many examples in the library if you do a search.
[quote]For example, testing a Component leaves me with:
*** Leaked objects detected: 1 instance(s) of class OSXTypeface[/quote]
To me, that seems like something that doesn’t require a unit test, per sé, but a pointer deletion. If you aren’t already aware of this class, check this out if you’re allocating stuff on the heap: juce::ScopedPointer.
What I personally do is create a bare-bones project with the Introjucer, and test little things out here and there… especially before moving anything into a main project.
My tests do not allocate memory, and it’s not about that specific leak either. I have also seen other things:
*** Leaked objects detected: 1 instance(s) of class MouseInputSourceInternal
I am wondering whether I have to e.g. initialise() and shutdown() a JUCEApplication in my test fixture to get all the required clean ups? Something else?
My tests do not allocate memory, and it’s not about that specific leak either. I have also seen other things:
*** Leaked objects detected: 1 instance(s) of class MouseInputSourceInternal
I am wondering whether I have to e.g. initialise() and shutdown() a JUCEApplication in my test fixture to get all the required clean ups? Something else?[/quote]
Yeah, you have to shutdown the system. See the stuff in juce_Initialisation.h