[Rule Request] Don't allow @testable imports outside of tests

[marcelofabri]

New Issue Checklist

• [x] Updated SwiftLint to the latest version
• [x] I searched for existing GitHub issues

New rule request

1. Why should this rule be added? Share links to existing discussion about what the community thinks about this.

@testable import is meant to be used in unit tests target only. While it's hard to tell whether we're in an unit test target, we could use some heuristics:

• Is this file importing XCTest/Quick/Nimble? or
• Is there a XCTestCase/QuickSpec subclass?

2. Provide several examples of what would and wouldn't trigger violations.

//ok
@testable import Foo
import XCTest

// not ok
@testable import Foo

4. Should the rule be configurable, if so what parameters should be configurable?5.

• Severity
• Test frameworks - used to configure the search for imports (default: [XCTest, Quick, Nimble])
• Test subclass (default: [XCTestCase, QuickSpec])

6. Should the rule be opt-in or enabled by default? Why? See README.md for guidelines on when to mark a rule as opt-in.

Opt-in. By its nature, this rule will have false positives.

[akuzminskyi]

Hi, can you please explain why we can't use @testable in a demo app project that for example contains some internal sample views or mock some internal data?

[AnthonyBY]

@testable import works fine for internal target, but if the library is outside of tests, it actually prevents Xcode from building a release

❌ /Users/centaur/Library/Developer/Xcode/DerivedData/AppName-fqccwulaixyxqfgtjtejiceyhulw/SourcePackages/checkouts/appName/Mocks/MyTocken.swift:1:1: module “MyModule” was not compiled for testing
@testable import MyModule

you can workarround it by setting -enable-testing for release target, but it will be nice if SwiftLint can highlight this beofre

[markst]

wonder if such a rule could be made using a custom_rules