{"id":40380,"date":"2023-08-17T14:35:00","date_gmt":"2023-08-17T18:35:00","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=40380"},"modified":"2023-10-11T16:44:15","modified_gmt":"2023-10-11T20:44:15","slug":"how-to-automate-memory-leak-detection-with-xctest","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2023\/08\/17\/how-to-automate-memory-leak-detection-with-xctest\/","title":{"rendered":"How to Automate Memory Leak Detection With XCTest"},"content":{"rendered":"

Dan Torres<\/a>:<\/p>\n

Inside the addTearDownBlock<\/code>, we can assert if sut<\/code> and spy<\/code> are deallocated by asserting if they’re nil<\/code>. We hold sut<\/code> and spy<\/code> with weak references so that they won’t be strongly retained when executing the block. <\/p>

[…]<\/p>

But adding this block to all your tests may reduce readability. So we can add an extension to XCTestCase<\/code>, which will allow us to use it in any test. We would also add the file and line so the failure message can be at the exact line and file where the test failed.<\/p><\/blockquote>\n

I’ve found this sort of thing very helpful. I don’t recall why I didn’t use weak closure captures. Instead, I’ve been using associated objects that fulfill XCTestExpectation<\/code>s when they’re deallocated. Sometimes it takes a run loop cycle before objects are deallocated.<\/p>\n

In order for this to work, you have to be careful of when you and Cocoa autorelease objects. For example, creating an NSWindow<\/code> or setting its title will end up extending the life of its view controller. So does changing the selected tab view item or some other tab view properties. You may think you’re avoiding leaks by using NSHashTable<\/code> to store weak references, but adding or reading the objects causes them to be retained and then autoreleased.<\/p>\n\n

See also: Bruno Rocha<\/a>, Paul Samuels<\/a>, John Sundell<\/a>.<\/p>\n\n

Previously:<\/p>\n