文章引用自:swifter.tips
在软件开发中，测试的重要性不言而喻。Xcode 中集成了 XCTest 作为测试框架，Swift 代码的测试默认也使用这个框架进行。
关于 XCTest 的使用方法，比如像setUp，tearDown以及testxxx等在 Swift 下和以前也并没有什么不同，作为一本介绍 tip 的书籍，我不打算在此重复这些。如果对测试的理论基础和实践方法感兴趣的话，不妨看看 Objective-C 中国上相关的话题文章。
XCTest 中测试和待测试的 app 是分别独立存在于两个不同的 target 里的。这在 Swift 2.0 之前使测试 Swift 代码时面临了由访问权限带来的巨大困境。在 Objective-C 时代，测试的 target 通过依赖应用 target 并导入头文件来获取 app 的 API 并对其进行测试。而在 Swift 中因为 module 模块的管理方法和访问控制权限的设计，使得这个过程出现了问题：一般对于 app，我们都不会将方法标记为public，而会遵循访问权限最小的原则，使用默认的internal或者是private。对于有些internal的方法，其实我们是需要去进行测试的。但是由于测试的 target 和 app 的 target 是不同的，因此在测试中导入 app 的 module 后我们是访问不到那些默认internal的待测试方法的，这就使得测试变得不可能了。
如果我们正在开发的是一个类库的话，为了别人能导入和使用我们的库，我们需要把对外的方法和成员都标记成public，这样我们就能直接在测试 target 中导入类库 target 并访问到待测试 API 了：
// 位于框架 target 的业务代码publicfuncmethodToTest(){}// 测试importMyFramework//...functestMethodToTest(){// 配置测试someObj.methodToTest()// 断言结果}
对于类库来说，这种做法是没什么问题的 -- 那些被标记为public的东西恰好就是需要被测试的代码接口。但是对于 app 开发时的测试来说，我们需要尽可能地控制访问权限：我们没有理由为一些理论上不存在外部调用可能的代码赋予public这样高级的权限，这违背了最小权限的设计原则。对 app 的测试在 Swift 1.x 的时代中一直是一个很麻烦的问题。而在 Swift 2.0 中， Apple 为 app 的测试开了“后门”。现在我们可以通过在测试代码中导入 app 的 target 时，在之前追加@testable，就可以访问到 app target 中internal的内容了。
// 位于 app target 的业务代码funcmethodToTest(){}// 测试@testableimportMyApp//...functestMethodToTest(){// 配置测试someObj.methodToTest()// 断言结果}
