The Architecture Journal:Test-Driven Development and Continuous Integration for Mobile Applications

Test-Driven Development and Continuous Integration for Mobile Applications

测试驱动的移动开发和持续集成





by Munjal Budhabhatti

Summary: This article demonstrates how test-driven development and continuous integration addresses the unique challenges encountered when creating Windows Mobile applications.

摘要：本文描述了如何利用测试驱动的开发和持续集成来解决移动应用开发带来的挑战

Contents

Current State of Mobile Development: Issues and Challenges

Test-Driven Development

Unit testing

Continuous Integration

Source Code Repository

wMobinium.net

Faster Successful Builds

Benefits of Using CI

Conclusion

Resources

About the Author

Current State of Mobile Development: Issues and Challenges

目前移动开发的状态：问题和挑战
Globally, the number of mobile phone subscribers is approximately 2.5 billion and is expected to grow to 4 billion by 2010. The mobile device is now a richer platform for application delivery due to such an exponential growth and wide spread usage. The critical factor, as always, is the end user experience: application usability, reliability, and performance.

全球移动手机订阅数量大约为25亿，预测到2010年这个数字还会增长到40亿。如此快速的指数增长和广泛应用使得移动设备成为应用程序的一个更加丰富的平台。 其中至关重要的因素依然是用户体验：可用性，可靠性和性能。

Complicating matters, the software development world is moving from weekly and monthly deployment cycles to continuous deployment. So how can one ensure that a user always has the best experience?

复杂的问题是，软件开发正从每周和每月的部署周期到不断部署。因此，如何才能确保用户始终拥有最好的体验？

Many that have looked at the agile space will be familiar with two of the core extreme programming practices: The driving of development with automated tests, a style of development introduced by called test-driven development; and a software development practice of frequently integrating builds called continuous integration, as articulated by Matthew Foemmel and Martin Fowler.

许多已经研究过敏捷领域的人都会熟悉两个核心极端编程做法：基于测试驱的开发与自动化测试，既Kent Beck引入的被称之为测试驱动开发;和Matthew Foemmel 和Martin Fowler阐述的软件开发实践中经常应用的持续构建。
These practices are not new to the software world. However, mobile application development has lagged in taking advantage of the test-driven development and continuous integration endowed by the enterprise software community. This is partially a result of limited or unavailable mobile platform support in existing toolsets such as NUnit/MSTest or Cruisecontrol.net/Team Foundation Server.

这些实践对软件来说并不陌生。然而移动应用程序开发在利用企业软件社区支持的测试驱动和持续集成方面依然落后。一部分原因是现存的测试工具比如 NUnit/MSTest和Cruisecontrol.net /Team Foundation Server对移动平台的支持有限。

A few mobile testing tools allow recording user interactions via a graphical representation of the client device but do not provide granular control over the tests. Other tools either demand scripting on a mobile device or expect tests to be executed, manually, on the device. As a result, mobile application testing is inefficient and complex, hindering productivity.

一些移动应用的测试工具允许通过客户端设备的图形表示来记录用户交互但是不提供测试过程中的单元控制。其他的工具或者要求在移动设备上编写脚本或者手工执行测试。这导致移动应用程序测试的复杂和低效率，同时妨碍的生产率。

Test-Driven Development

Test-driven development (TDD) is an evolutionary approach where the development of code is driven by first writing an automated test case, followed by writing the code to fulfill the test and then refactoring.

测试驱动(TDD)是一个进化的方法：首先要写自动测试用例来驱动开发，再开发满足这个测试的代码，然后重构。

TDD essentially is test-first development + refactoring

TDD 实际上是测试先行的开发＋重构

Red/Green/Refactor—the TDD mantra—is an order to the task of programming:

红/绿/重构－TDD的颂歌－既编程任务的顺序

Red: Write a small automated unit test that doesn’t pass, and perhaps doesn’t even compile at first. (See Figure 1.)

Green: Write the code necessary to pass the failing test. Ensure other tests pass as well, if present, in the suite. Check-in the code in the source code repository. (See Figure 2.)

Refactor: Making existing code beautiful, in small incremental steps, without changing the intent. (See Figure 3.)

红: 写一小段自动不能通过的单元测试，甚至一开始都不能编译。（如图1）

绿: 写必须的代码使得测试能够通过。同时保证其他在test suite中的的测试也能通过。（如图2）

重构: 再不改变程序意图的前提下通过增量的步骤使代码更加优雅。（如图3）



Figure 1. Sample test cases



Figure 2. Sample code



Figure 3. Sample refactoring

This technique is thus reverse to traditional programming—developing code followed by writing a test, which is executed either manually or automatically. Why embrace such a change, especially when one might tend to think that it’s extra work? In reality, test-driven development is risk-averse programming, investing work in the near term to avoid failures (and even more work) in the late term—Kent Beck has called it “a way of managing fear during programming.”

这种技术因此颠覆了传统的编程，开发代码然后写手工的或者自动的测试用例。有人可能会认为这是额外的工作，为什么要接受这种改变？事实上，测试驱动开发是一种降低风险的编程模式，在短期工作中的投入会避免长期的失败（甚至更多的工作）－Kent Beck 称之为“在编程中管理恐惧的一种方法”。

“Test-driven development is a way of managing fear during programming—fear not in a bad way—but fear in the legitimate. If pain is nature’s way of saying ‘Stop! ’ then fear is nature’s way of saying ‘Be careful.’”—Kent Beck

测试驱动的开发是在编程中管理恐惧的一种方法－恐惧不是坏东西－而是合情合理的。如果痛苦是说“停下”那么恐惧就是“小心”－Kent Beck

The benefits of TDD

Design improvement. Writing a self-contained test case enforces the creation of decoupled code—not tightly integrated with other code—thereby increasing the cohesion of the code while decreasing the coupling.

Documentation. A well-written unit test case provides a working specification and communicates the intent of the code clearly. In addition, whenever the code changes, the unit test case must be updated to pass the test suite. Hence, a unit test case always stays in sync with the code naturally. This is unlike traditional unit test cases, developed with Microsoft PowerPoint or Microsoft Word. While such documents start off with good intentions, over time, the result often becomes out of sync with the underlying implementation.

Safe change in the system. TDD provides continuous feedback about whether the changes made in the code worked well with the other parts of the system.

Fail fast. Unit testing can isolate problems quickly, reducing debugging activities and allowing the system to fail fast.

Beautiful code. Beautiful code means code which expresses intent clearly, can afford changes to add features, and has no duplication. Refactoring retains the behavioral semantics of the code—functionality is neither added nor removed. It is about improving the code quality which brings business value.

TDD的好处

设计上的进步. 开发自包含的测试用例强迫代码的解藕－不要和其他代码的绑定－因此同时提升了内聚

文档. 一个写得很好的单元测试用例提供了一个工作文档并且清楚的传达了程序的意图。测试驱动开发中的单元测试用例总是于代码自然的同步。因此，不像传统的用Microsoft PowerPoint or Microsoft Word开发的单元测试用例，虽然从很好的意图开始，随着时间的流逝，结果是测试用例和实现脱节。

确保改变的安全性. TDD为改动是否与系统的其他部分正常工作提供持续的反馈

快速失败. 单元测试可以快速隔离问题，减少debug并允许系统快速失败。

漂亮的代码. 漂亮的代码意味着清楚的表达意图，可以修改以增加功能，没有冗余。重构保持了代码语意的行为－不是增加或减少功能，而是提高代码质量从而带来业务上的好处。

Automated unit test execution is one of the vital requirements of TDD. However, because the testing tools are still evolving, the automated execution is not currently viable in mobile application development. Implementing TDD in this environment is therefore quite challenging, if not impossible.

自动化的单元测试执行对TDD来说是一个至关重要的需求。然而因为测试工具仍然在进化中，移动应用开发中自动化执行目前还不可行。对这个领域来说实现TDD虽然不是不可能，但确是个挑战。

Unit testing

Testing is customarily thought to be as a methodical process of proving the existence or lack of faults in a system. When a test case is written before writing the code, the test case becomes a specification, instead of a mere verification of the feature.

测试通常被认为是一种有条理的过程用来证明系统中是否存在错误。 当测试用例先于代码开发的时候，测试用例就成了文档，而不仅仅是功能验证中的一部分。
Tests are also a way of documenting found defects. Let’s assume a defect was discovered in quality assurance while testing newly deployed bits. Even if this defect was very trivial to fix, TDD demands a test case. First, write a test case that simulates such a failing behavior, and then write code to pass the test. Such a practice would ensure that defects, no matter how petty, do not creep through the system and regression testing becomes part of the test suite. Automated test execution locally, before committing the changes to the , would further reduce the broken builds phenomenon.

测试也是文档化已发现缺陷的一种方法。我们假设在测试新部署的代码过程中发现了一个新的缺陷。即使该缺陷非常无关紧要，TDD也要求有一个相关的测试用例。首先，写一个测试用例以重现这个失败的行为，然后开发代码是测试通过。这确保了不管多么小的缺陷都不会在系统中潜伏并且回归测试成为整个test suite的一部分。自动化测试应该在提交修改到Source Control Repository (SCR)之前在本地执行以减少build失败。

It is important to prepare the test environment on an emulator as close to the target hardware as possible. Developing and testing Windows Mobile applications on an makes little sense when targeting hardware exclusively for ARM
architecture, an architecture dominant in low power consumption
electronics. Furthermore, in the real world, components often have
dependencies on other objects, databases, or network connections. It is
very easy to fall into a trap of assuming that these
dependencies work flawlessly. Hence if tests are written without taking
dependencies into consideration, an incorrect feedback is possible for
those tests which fail due to dependency problems.

在模拟器上准备尽可能接近目标硬件的测试环境非常重要。如果目标硬件是专门的ARM 架构，在x86 emulator 上开发和测试Windows Mobile应用程序毫无意义。此外，在现实世界中，组件常常依赖于其他的对象，数据库，或者网络连接。假设这些依赖完美的工作很容易落入陷阱。因此如果测试开发中没有考虑这些依赖条件，可能会得到不正确的反馈。

One way to safeguard against dependencies is to build the object graph or set up the database in a required state before executing the test case. This would solve the issue but would increase test execution time and build time.

一种保证依赖安全的方法就是在执行测试之前构建对象图或者安装数据库并配置好需要的状态。这可以解决问题但是可能提高了测试执行时间和构建时间。
A more elegant approach would be to instantiate test objects and replace object dependency by implementing mocks or stubs—objects that imitate the behavior of real objects. This ensures
isolated test execution and hence reliable test results. Caution should
be taken while faking the real objects with mocks or stubs. It is
probable that the entire unit test suite executes faultlessly, yet the
product might fail in quality assurance testing. I have found in my own
experience that complementing mocks and stubs objects with integration
tests provides a true sense of confidence.

更为优雅的方式是例示测试对象并通过实现mocks or stubs－对象模拟真实对象的行为来替换依赖。这确保测试的隔离执行因此得到可靠的测试结果。用mocks或者stub伪造真实对象需要谨慎的考虑。可能整个测试suite运行没有任何问题，然而产品在质量保证测试阶段可能失败。我已经再我自己的经验中发现了这一点，整合补充的mocks和stubs对象和测试会让你非常有信心。

Continuous Integration

持续集成

Martin Fowler has described continuous integration (CI) as a software development practice of frequently integrating builds, often multiple times a day. A typical CI workflow, as shown in Figure 4, would be:

Developer:

Writes a new unit test case.

Executes the unit test case locally on the emulator and confirms that the test case is failing.

Adds or modifies code to pass the test case.

Executes the unit test case locally on the emulator and confirms that the test case is passing.

Commits the code to the SCR.

CI Server:

Downloads the source code whenever there is a change in the SCR.

Compiles and inspects the source code, and creates new binaries.

Sets up external dependencies such as database schemas, and resources (configuration files, satellite assemblies).

Deploys the new binaries to and executes the tests on the emulator.

Packages and deploys the product to staging environment.

Generates feedback based on the results of the build.

Martin Fowler 描述了持续集成（CI)是一个频繁构建的软件开发实践，常常是每天构建几次。一个典型的CI工作流，如图4所示：

Developer:

开发新的单元测试用例

本地执行单元测试用例，确认测试失败

增加或修改代码使测试通过。

本地执行单元测试用例，确认测试通过

提交代码到SCR

CI Server:

只要SCR中有代码改动就下载源代码

编译和检查源代码，创建新的binaries

安装外部依赖如数据库表，和资源（配置文件，卫星程序集）

部署binaries到模拟器并执行之

打包并部署产品到staging环境

基于构建结果产生反馈信息



Figure 4. Continuous integration in .Net Windows Mobile application

Source Code Repository

All the essential files required to build a product reside in the source code repository (SCR). It plays an important role in the software development life cycle and CI. SCR tools such as Subversion and Visual Studio Team Foundation source control enable teams to work collaboratively—on the same or different artefacts simultaneously, track code changes effortlessly, and work on different versions of files concurrently.

所有构建产品的必不可少的文件都贮藏在SCR中。他扮演了软件开发生命周期和CI中一个重要的角色。SRC工具诸如Subversion和Visual Studio Team Foundation source control 使team能够协同工作－同时的工作在相同或不同的制品上，轻松的追踪代码更改，和并发工作在文件的不同版本。

The CI server obtains the latest source code from SCR, locates all required dependencies, and builds the product independently from the previous build output. SCR allows the team to be more productive—a new team member does not need to reconfigure third-party libraries, project structures, or IDE settings for the project. Moreover, it reduces debugging time by allowing the team to remove the current changes which would be small and incremental if using TDD practices. The system could be safely reverted to a previous version of the code.

CI服务器从SCR得到最新的源代码，定位所有需要的依赖，并且当前构建与前一构建的输出独立。SCR使team更加多产－一个新成员不需要重新配置第三方的库文件，项目结构，或者IDE设置。此外，如果使用TDD，通过允许team移除当前的小的或者是增量的改动减少了debug的时间。系统可以安全的回复到上一个版本。

It is vital to include all dependencies in the SCR: This includes the Windows Mobile SDK, .Net Compact framework installer, Virtual Machine Network service drivers and other third-party components and utilities.

在SCR中包含所有的依赖很重要：这包括Windows Mobile SDK，.NET Compact framework 安装包，Virtual Machine Network service driver 和其他的第三方组件和工具。

“Continuous integration is a software development practice where members of a team integrate their work frequently—usually each person integrates at least daily—leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly.”—Martin Fowler

“持续集成是一个软件开发实践：team成员频繁的集成他们的工作－通常每人每天集成一次－导致一天内集成多次。每一次集成由自动化构建（包括测试）验证以尽可能快的发现错误。很多team发现这种方式显著的减少了集成问题并允许team快速的开发有内聚力的软件。”

－Martin Fowler

Automated build

Contradictory to some misconceptions, the automated build in mobile applications is much more than a simple code compilation. It assembles source code from the SCR, compiles code to create binaries and dependencies (such as configuration objects, resource assemblies, and so forth), inspects and deploys compiled binaries to a mobile device or an emulator, loads database schemas, and executes tests remotely on the mobile device.

Build tools such as Nant and MSBuild do not support mobile application deployment, partially because mobile device support in these tools is still immature. In addition, unit testing tools such as NUnit and MSTest have a similar problem of executing tests remotely on a mobile device. To avoid these limitations a new tool is essential.

与一些错误的观念相反，移动应用程序的自动构建并非简单的代码编译。它从SCR组合源代码，编译代码生成二进制和依赖（如配置对象，资源程序集，等等），检查和部署已编译的bits到移动设备或者模拟器，家在数据库schema，和在移动设备上执行远程测试。

构建工具入Nant和MSBuild并不支持移动应用程序部署，部分因为这些工具对移动设备的支持不成熟。另外，单元测试工具如Nunit和MSTest在远程执行测试中也有同样问题。为了避免这些限制，一个新的工具是必不可少的。

wMobinium.net

To address these problems, I created a tool wMobinium.net which assists TDD and CI implementation in .Net mobile applications. wMobinium.net is a unit testing tool that supports automated deployment and automated remote unit test execution. It has a Visual Studio add-in to support TDD in .Net mobile applications. It is a freely available tool on the CodePlex open source Website (see Resources).

为了解决这些问题，我创建了一个工具：wMobinium.net 来帮助在.NET移动应用中实施TDD和CI。 wMbinium.net 是一个单元测试工具，他支持自动化部署和自动化的远程单元测试执行。提供VisualStudio add-in来支持TDD。他是一个在CodePlex开源网站上的免费工具（见resource）

Automated deployment

Unlike desktop application development, mobile application development faces unique challenges in deployment: first, a deployment is required for unit testing features on the device and second, deployment is necessary after a successful build to deliver the working solution on a staging environment for quality assurance testing.

For every build, the newly compiled binaries and dependencies must be copied to a program folder on a device. When an application entails testing on multiple devices, there will be added complications to the deployment process. To circumvent these problems, wMobinium.net offers a deployment tool which implements Window CE’s Remote Application Programming Interface (RAPI), and facilitates file and folder deployments. This relieves the pain of manual deployments.

不像桌面应用程序开发，移动应用开发在部署上面临特有的挑战：首先，必须在设备上部署才能进行单元测试；其次成功构建之后需要部署到staging 环境中进行质量保证测试。

对于每次构建，新编译的binaries和依赖必须被拷贝到设备的程序目录中。当一个应用限定测试需要在多个设备上，出现了新的部署的难题。为了克服这些问题，wMobinium.net提高你关了一个部署工具，用Window CE的RAPI实现，轻松文件和目录的部署。

Frequent commits

One of the key components for a successful CI implementation is frequent commits and hence frequent builds. With longer commit intervals, team members tend to work in isolation and the build is more prone to integration issues. When a team member spends more time on a feature and encounters integration problems while committing the code, he tends to be reluctant to remove the changes and revert to a previous version of the code. This reluctance might increase the amount of time and resources spent on debugging activities. In an ideal scenario, team members check-in the code at intervals of 30-60 minutes or less. The check-in duration could be extended by a few hours, but should always be less than a day.

成功实施CI的一个关键是频繁的提交和由此导致的频繁的构建。对于较久的提交周期，team成员倾向于单独工作并且构建更倾向于集成的问题。当一个成员在一个功能上花费了较多的实践并在提交的时候遇到了集成的问题， 他试图勉强的移除改动，会滚到上一版本的代码。这可能增加了debug上所花的时间和资源。再一个理想的情境下，成员应该在30－60分钟的间隔下checkin代码。checkin的间隔可能在几个小时，但是至少每天一次。

Faster Successful Builds

Once a developer commits code to the SCR, waiting for the feedback from CI slows down the development process. Longer waits result in decreased productivity. Furthermore, some of the subprocesses of the build, such as deployment and testing, are executed on a device/emulator making these processes inherently slower than it would have been on a desktop.

To reduce build times, concentrate on the weakest link—the component that takes the longest time to execute. More often than not, the cause would be an external dependency, such as a database or other objects. Accessing a database and setting up test data for each test case is a resource-intensive operation. As I mentioned earlier, mocks or stubs, should do the trick. If it is impractical to do so, move the test cases to secondary or nightly builds—scheduled builds that execute at night when most of the resources are idle. Test cases targeting tests scenarios on multiple devices should be added to secondary or nightly builds as well.

Failing builds cause the most frustration—as if the entire chain of software churning has been stopped. The code in the SCR is no more reliable and the team is blocked from getting the latest source code. The team needs to resolve the issue quickly by fixing the build. If a test case is causing the failure and fixing the problem might require a longer duration, it is safe to ignore the test case temporarily to allow the build to succeed. However, it is vital to track these ignored test cases on an easily accessible project wall, a physical white board or a virtual board using collaborative software. The ignored tests should be fixed at a later time and added back to the test suite.

一旦开发者提交代码到SCR，等待CI反馈使得开发进程变慢。长时间的等待造成生产率下降。此外，一些构建中的子流程，如部署和测试，执行的设备/模拟器使这些过程本质上慢于本地的桌面。

为了减少构建时间，集中力量最薄弱的环节－考虑执行时间最长的组件。更多的往往是一个外部的依赖，如数据库或其他物体。访问一个数据库，并建立测试数据为每个测试案例是一个资源密集型操作。正如我刚才所说，mocks或者stubs，是可以采取的技巧。如果这样做是不可行的，把测试用例转移到第二级或者夜间构建－－构建可以被预定在夜间利用大部分资源闲置的时间执行。测试案例中的针对多种设备的测试方案也应该被转移到夜间构建中。

失败的构建最令人沮丧，仿佛软件制造链被停止。SCR中的代码不再可靠和整个team因为不能获取最新的正确代码而被卡住。该小组需要解决问题并迅速修复构建。如果一个测试案例造成失败而解决这个问题可能需要较长的时间，可以暂时的忽视测试案例并允许构建成功。然而，重要的是在项目中容易的追踪这些暂时忽略的测试案例，可以试用白板或一个协同软件（bugzilla）。暂时忽略的测试应在稍后的时间修复并增加回测试suite。
Automated unit testing

It is quite common to see that the same defects resurface after a few builds and we often hear a quality assurance analyst say, “but this defect was already fixed in a previous build.” Boomerang defects reveal the importance of writing a test for each encountered defect before modifying the code base. Once the test case is fixed, the entire test suite must be executed and passed before checking in the modified code to the SCR.

经常能看到在几次构建之后相同的缺陷又出现的现象，也常常听到质量保证分析员抱怨，“我们已经在以前的构建中修复了这个bug”。反复出现的缺陷反映了在改动代码之前为每一个bug开发一个测试用例的重要性。一旦确定了测试用例，在提交修改到SCR之前，整个测试suite必须被执行并且要确保通过。
I have been on a few projects where the team executes the test suite manually on a mobile device. Imagine a mobile application developer who spends few minutes changing the functionality, but spends double the time to test it manually. This will not only discourage a developer but will also affect productivity.

wMobinium.net resolves this annoyance by automating the entire unit testing workflow. Unlike traditional unit testing, wMobinium.net presents the test case selection on the desktop, executes tests on the device, and displays results on the desktop. It takes care of some of the complications such as the following:

我曾经为几个在移动设备上手工执行测试用例的项目工作。想象一下一个移动应用开发者花几分钟的时间改动一个功能，但是要花双倍的实践来手工测试。不但令人气馁也影响生产率。

wMobinium.net通过自动化真个单元测试流程解决了这些问题。不像传统的单元测试，wMobinium.net在本地展示测试用例的选择，在远程设备上执行，并在本地展示测试结果。他解决了如下的复杂问题：

Remote execution of test cases

In order to execute the test cases remotely on a mobile device/emulator, the tool serializes metadata information of the selected test cases, starts a conduit process and executes tests on the device. To provide correct reporting to the CI server, the remote process must be started synchronously and monitored continuously, which is quite a challenge.

远程执行测试用例

为了在移动设备商远程执行测试用例， 这个工具将选择的需要运行的测试用例元数据序列化，启动一个管道进程并在设备上执行测试。为了向CI服务器提供正确的测试报告，远程进程必须同时启动并不停的监控测试过程，这是一个相当的挑战。
Serializing test results to desktop

In the absence of support for remoting in the .Net Compact Framework version 2.0, the device must communicate with the desktop using sockets. The events must be serialized, sent to the desktop through a socket, deserialized, and propagated to the appropriate event listeners.

序列化测试结果到本地

.Net Compact Framework version 2.0 不报含对remoting的支持，设备必须通过sockets和本地通信。 事件被序列化，通过socket发送到本地，反序列化然后传播到合适的实践侦听程序。
wMobinium.net add-in

The tools described here assist the CI server to continuously build, deploy, and test a .Net mobile application. It would be convenient if the unit testing feature was supported as an integrated tool in Visual Studio.

wMobinium.net add-in, a Visual Studio add-in (Figure 5), is a part of the wMobinium.net toolset. After activating the add-in, all the available tests in the solution are displayed in the tool window. A typical workflow would be:

wMobinium.net tool displays available test cases in a solution.

User selects test cases to execute.

Selected test cases are serialized and sent to the connected device/ emulator.

Test cases are executed on the device/emulator and results are sent back to the desktop.

Tool displays results on the desktop.

wMobinium帮助CI服务器持续的构建，部署和测试.NET移动应用程序。如果单元测试功能能够作为Visual Studio的一个整合工具那会非常方便。

wMobinium插件，一个Visual Studio 插件（图5），是wMobinium.Net工具集的一部分。在激活插件后，所有解决方案中可用的测试显示在工具窗口。一个典型的工作流：

1. wMobinium.net 工具显示解决方案中的可用测试用例

2. 用户选择测试用例以执行

3. 被选择的测试用例被序列化到链接的设备或者模拟器

4. 测试用例在设备或者模拟器上被执行，测试结果返回本地。

5. 工具在本地显示测试结果



Figure 5. wMobinium.net add-in

Benefits of Using CI

Stakeholders and project sponsors always favor reliable outcomes, clear communication, project visibility, and superior quality of software. Software development, however, seldom offers such qualities without the right processes and practices.

When everything seems to be going well, any defect might suddenly jeopardize the development schedule. Especially during “Big-bang” integrations, even small issues—like missing configuration entries, out-of-sync database, or missing dependencies—could be extremely detrimental when encountered together.

Continuous integration enables faster feedback. At every change—adding new or modifying existing features, no matter how big or small—the CI server would integrate the new parts which would pass through the entire automatic build cycle—compilation, testing, inspection, and deployment. This provides visibility of the progress of the project, enhances the quality of the software developed, and builds the morale of the team.

CI does not provide these functionalities out-of-the-box. It is very possible to implement CI without including automated tests or inspection in the builds process; however, such a setup would be the least beneficial. Many, including me, consider that CI without testing is not CI at all.

项目相关人总是喜欢可靠的结果，清晰的交流，项目的可视化和出色的软件质量。然而，没有正确的流程和实践软件开发很少能达到如此良好的品质。

当一切看起来运行良好，任何缺陷都可能突然影响开发计划。特别是在大量的整合中，任何小问题－比如丢失配置项，数据库不同步，丢失依赖项－当它们一起出现的时候简直糟透了。

持续集成可以更快的得到反馈。每一次改动－增加或者修改现存的功能，不管是大是小－CI服务器整合这些新的部分，它们应该通过整个自动构建周期－编译，测试，检查和部署。这提供了项目进程的可视化，增强了软件开发的质量，并且提高了整个team的士气。

自动构建并不提供开箱即用的功能。很有可能实现一个不包含测试和检查的CI构建过程；然而如此的一个安装过程也是有用的。很多人包括我都认为没有测试的CI不是一个真正的CI。

Conclusion

From a user perspective, TDD and CI implementation is the same in a traditional desktop application as it is in a mobile application. The user creates a new failing automated test case, writes the code to pass the test, and refactors the code without changing the intent. The CI server polls for the latest source code creates new binaries, executes the tests, and generates the feedback. However, in a mobile application the implementation differs in the remote execution of test cases, notification of test results, and build deployments. These complexities are handled by the wMobinium tool.

In my past experience at one of the biggest microfinance organizations in Africa, my team and I developed a .Net mobile application. In the absence of supporting tools, the development implementing TDD and CI, although arduous, improved overall application design, reliability, and performance.

With the release of .Net Compact Framework version 2.0, the performance of .Net mobile applications has improved radically. The newer version provides improved developer productivity, greater compatibility with the full .Net framework, and increased support for device debugging. Combining .Net Compact Framework with TDD and CI (using wMobinium.net) would bring greater benefits to an organization and take the mobile application platform to the next level.

With the proliferation of new mobile devices today, the mobile application is becoming a crucial part of a broader enterprise product offering. It is pragmatic, more than ever, to bring mobile application development out from isolation and include it in enterprise-wide test-driven development and continuous integration efforts.

从用户的观点看，在传统的桌面程序的TDD和CI实现和在移动应用程序中是一样的。用户创建一个失败的自动测试用例，开发代码使测试通过，然后在不修改代码意图的情况下重构代码。CI服务器使用最新的代码得到新的二进制文件，执行测试，然后生成反馈。然而，在移动应用程序中远程执行测试用例，通知测试结果，并且部署都与桌面程序不同。这些复杂性都可以通过wMobinium工具处理。

之前我在非洲最大的金融组织中的经验中，我的team和我开发了一个.NET移动应用程序。在缺少支持工具的情况下，使用TDD和CI开发虽然艰苦，但是提高了整个应用程序的设计，可靠性和性能。

随着.Net Compact Framework version 2.0的发布，.Net mobile application的性能得到了快速的提升.最新的版本提供了更高的生产率,更多和完整.NET架构的兼容性,也提升了设备debug的支持..Net Compact Framework ,TDD 和CI(使用wMobinum.net) 的结合为组织带来更大的好处并把移动应用开发提高到一个新的层次.

在新的移动设备蓬勃发展的今天,移动应用程序正在变成广泛的企业应用产品提供的一部分.将移动应用程序开发从孤立带入企业级别的测试驱动开发和持续集成比以往任何时候都更具有实际意义.

Resources

“Continuous Integration,” Martin Fowler and Matthew Foemmel http://www.martinfowler.com/articles/continuousIntegration.html

Continuous Integration: Improved Software Quality and Reducing Risk, Paul Duvall, Steve Matyas, and Andrew Glover (Addison-Wesley Professional, 2007)

Test-Driven Development: By Example, Kent Beck (Addison-Wesley Professional, 2002)

wMobinium.net http://www.codeplex.com/wMobinium

About the Author

Munjal Budhabhatti is a senior solution developer at ThoughtWorks. He possesses over 10 years of experience in designing large-scale enterprise applications and has implemented innovative solutions for some of the largest microfinance, insurance and financial organizations in Africa, Asia, Europe, and North America. He spends most of his time writing well-designed enterprise applications using agile processes.

This article was published in the Architecture Journal, a print and online publication produced by Microsoft. For more articles from this publication, please visit the Architecture Journal Web site.

Munjal Budhabhatti 是ThoughtWorks的高级解决方案developer.他拥有10年的大型企业应用程序设计经验,为很多非洲,亚洲,欧洲和北美的大型金融,保险和财务组织实现了革新性质的解决方案.他花了大量的时间撰写用敏捷过程设计良好的企业应用程序.

本文发表于Architecture Journal,微软的可打印的和在线产品.更多细节,请访问Architecture Journal Web site.