移动应用程序现在已经非常普及,大多数的应用可以支持3种主流平台:iOS、Android和Windows phones。此外Firefox OS平台的市场占有率也在不断提升中。 应用程序的功能是与平台无关的。但是不同的平台还是会有差异,例如处理消息事件的方式等。测试移动应用程序,并保证它们能在所有的平台上正常工作,是一项很有挑战的工作。我们需要为不同的平台编写不同的测试用例并且分别执行。这样就会导致各个平台上的测试覆盖率不一样,而且测试用例也会变得原来越难维护。平台级别的差异实际上和应用程序的功能是无关的,所以理想的中的测试用例应该纯粹使用业务语言进行描述。 行为驱动开发(BDD)风格的测试可以极大地改善这种情况。
为什么使用BDD?
BDD风格的测试用例使用纯业务领域的语言进行描述。这种方式提供了一种更好的理解测试用例的途径。测试用例使用了高层次的逻辑表述,而不会包含具体的实现细节(例如点击一个按钮)。 BDD方法有很多工具的支持,这些工具可以把测试案例规范和底层实现细节关联起来。这种风格的测试已经被证明是易于维护的,也易于描述测试用例。 针对移动应用程序,BDD可以在以下方面提供帮助:
1
对底层细节进行抽象并提供高层次的步骤(steps):
BDD对底层细节进行抽象,并提供高层次的测试用例步骤,这样就会与平台无关了。下面来看一个发短信的应用程序的测试场景。这个测试使用Twist编写而成。
上面的测试不涉及任何的底层实现,而是使用了平台无关的语言,用业务术语描述测试场景。在这个测试用例中,接收消息提示是一个业务上的术语,对它的实现将会针对平台而不同。
2
因此这种测试用例可以被不同平台和团队使用:
会有一个通用的接口来负责和不同的实现进行交互。
public interface MessagingDriver { void login(String userName); void sendMessage(String toAddress, String message); void checkForNotifications(String address); }
现在每个平台可以有特定的实现了:
public class AndroidMessagingDriverimplements MessagingDriver {
public void login(String userName) {
// login for android
}
public void sendMessage(String toAddress,String message) {
// send message for android
}
public void checkForNotifications(Stringaddress) {
// check for notification for android
}
}
这样,测试实现仅仅需要去使用工厂模式和事先设置好的合适的环境变量,测试运行的时候会自动匹配相对应的平台驱动。 测试数据和测试场景不再需要重复,它们被视作一个可以执行的文档,从而共享给同一个应用的不同平台的团队。
public class MessagingDriverFactory {
public static MessagingDrivergetMessagingDriver() {
String testPlatform =System.getenv("TEST_PLATFORM");
if (testPlatform.equals("android")) {
return new AndroidMessagingDriver();
} else if (testPlatform.equals("ios")) {
return new IOSMessagingDriver();
}
throw new RuntimeException("Failed to find animplementation");
}
}