# Own Your Abstractions

DevFeed: [Own Your Abstractions](<https://devfeed.tech/articles/own-your-abstractions-25810.md>)

Original publisher: [Read original article](<https://www.steveonstuff.com/2019/09/12/own-your-abstractions>)

Author: Steve Barnegren

Published: 2019-09-12T00:00:00Z

Content type: opinion

Language: en

Sources: [Steve Barnegren](<https://devfeed.tech/sources/steve-barnegren.md>)

Topics: [Swift](<https://devfeed.tech/topics/swift.md>), [Testing](<https://devfeed.tech/topics/testing.md>), [Protocol (disambiguation)](<https://devfeed.tech/topics/protocol.md>), [Filesystems](<https://devfeed.tech/topics/filesystems.md>)

Tags: [objective-c](<https://devfeed.tech/tags/objective-c.md>), [protocol](<https://devfeed.tech/tags/protocol.md>), [shadowing](<https://devfeed.tech/tags/shadowing.md>), [swift](<https://devfeed.tech/tags/swift.md>), [test](<https://devfeed.tech/tags/test.md>), [testing](<https://devfeed.tech/tags/testing.md>)

## AI overview

The article examines a Swift testing technique that mirrors an external concrete type with a protocol and uses mocks for dependency isolation. It argues that this shadowing approach can hide deprecation warnings and encourages designing semantic abstractions instead of replicating awkward APIs.

## Source excerpt

If you want to test your Swift code, at some point you're probably going to need to make some mocks in order to isolate a type that you're testing from system apis. For instance, if your type calls UNNotificationCenter, then in your tests you don't want it to call the real UNNotificiationCenter, but rather a mock substitute that you control.