iOS项目的持续集成及管理.docVIP

iOS项目的持续集成与管理 当实现新功能时，如果忽略可维护性而引入技术债务，那将会需要延迟解决它或导致增加维护成本。 最近我们已经思考通过哪些方式来提高代码的质量： 当代码的质量下降时，通过设置一些工具来马上提醒开发者 文档化一些编码规范和思考在过去的几个项目中如何避免维护性差的问题 我将会简单地概括我们需要设置什么才能自动监控代码质量. 基础 我们选择一个持续集成工具Jenkins，让它运行在一台放在我们工作室的Mac Mini。其实我不怎么喜欢Jenkins，但到目前为止，它是最稳定和最适合的工具来完成这些工作。 我们已经通过Homebrew和rbenv来分别安装Jenkins和Ruby，而rbenv能够为我们提供一个最新和稳定的Ruby Gems环境。有个Homebrew和Ruby Gems两个包管理工具之后，我们就几乎能够安装所有我们需要的工具，但很少会破坏与原有OS X系统更新提供的Ruby。 单元测试 我们使用Specta和Expecta来测试我们的iOS项目。 Specta让我们采用行为驱动开发(BDD)风格的语法来编写测试，相比于XCTest的语法，它更加易读。它还有一个强大的分组测试功能，在测试之前或之后运行一些代码块，这样的话，能够极大地减少重复代码。 Expecta是一个匹配器框架，我们可以在测试中使用它来创建断言。它的语法非常强大，与此同时，它比内建的XCAssert套件更加易读。例如： 1 2 3 4 expect(@foo).to.equal(@foo); expect(foo).notTo.equal(1); expect([bar isBar]).to.equal(YES); expect(baz).to.equal(3.14159); 我们在开发时，通过XCode来运行测试；而使用通过Homebrew来安装的Jenkins时，会借助XCTool。XCTool是一个可代替的选择来xcodebuild，它能让你通过命令行的方式来非常轻松地运行测试套件和生成JUnit风格的测试报告。 1 $ xctool -workspace Project.xcworkspace -scheme Project -reporter junit:junit-report.xml test 这些测试报告会发布在Jenkins上，而Jenkins会使用JUnit Plugin来根据时间的推移提供单元测试结果的图表，同时会向我们显示我们的测试是否稳定。 Pull Request测试 我们想我们的测试尽可能运行以至于如果我们破坏什么东西，我们就会马上知道。我们在feature branches做些修改，然后提交一个pull request到Github，那么代码就会被另一个开发者审查。只要被打开，我们就能运行所有的测试来确保没有任何东西被破坏。 当新的pull requst是开放状态时，为了管理这些，我们安装Github Pull Request plugin来将信息从Github发送到Jenkins。如果有任何测试失败，它将会显示在Github，然后我们就不将代码合并，直到代码被修复为止。 代码覆盖率 我们也会用Gcovr工具来生成代码覆盖率报告，Gcovr的安装方式也是Homebrew。你需要针对main target的debug congfiguration改变两个构建设置来配置项目。将Generate Test Coverage Files和Instrument Program Flow都设置为YES。 当我们运行单元测试来生成代码覆盖率报告时，我们需要将OBJROOT=./build添加到XCTool命令行的尾部。 1 $ gcovr -r . — object-directory build/Project.build/Debug-iphonesimulator/Project.build/Objects-normal/x86_64 — exclude ‘.*Tests.*’ — xml coverage.xml Gcovr输出的代码覆盖率报告也会被插件Cobertura Jenkins plugin发布，这个插件会提供一种可视化的方式来根据时间的推移来显示代码覆盖率。 现在我们不仅可以看到测试是否通过，还可以看到代码的测试覆盖范围。甲骨文软件人才创新发展中心欢迎您！ 静态分析 在工具集中，其中一个强大并能够保持高质量的代码的工具就是静态分析工具。这些工具会扫描你的代码，然后生成一个报告，这个报告会告诉你破坏代码风格规则的代码位置。举几个规则的例子： 未使用的变量或参数 长变量名，方法名或代码行 覆盖一个方法，但没有在这个方法调用super 方法太长或方法过于复杂 还更多的规格… 我们使用OCL