{"id":28447,"date":"2020-03-24T16:52:39","date_gmt":"2020-03-24T20:52:39","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=28447"},"modified":"2020-03-24T16:52:39","modified_gmt":"2020-03-24T20:52:39","slug":"making-swift-properties-overridable-only-in-debug-builds","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2020\/03\/24\/making-swift-properties-overridable-only-in-debug-builds\/","title":{"rendered":"Making Swift Properties Overridable Only in Debug Builds"},"content":{"rendered":"

John Sundell<\/a>:<\/p>\n

\n

Occasionally, we might want to override certain properties in order to facilitate testing, to be able to work on a new feature, or to debug a problem.<\/p>\n

[…]<\/p>\n

Here’s a way to mitigate that problem, using Swift’s new property wrappers<\/a><\/em> feature in combination with the DEBUG<\/code> compiler flag. By creating a DebugOverridable<\/code> property wrapper, we can enforce that the properties that we wish to override during testing and development are not actually overridden within any of our code that we’re shipping to production[…]<\/p>\n<\/blockquote>\n

This is a neat trick, though unfortunately property wrappers don’t work with @NSManaged<\/code>. What I have been doing is having my tests use underscored versions of the properties. These are a declared in an extension, which is conditionally compiled only when the TEST<\/code> flag is set.<\/p>\n

I’d still like to see Swift’s access controls reworked to make testing easier. @testable import<\/code> doesn’t really do the job because it only works for symbols that are already visible at the package level. So you can only use private<\/code> for stuff that will never be used from tests.<\/p>\n\n

Previously:<\/p>\n