澳门新葡萄京娱乐场 2

Android 中构建快速可靠的 UI 测试

前言

让本人一块儿来寻访 Iván Carballo和她的团体是如何运用Espresso, Mockito
和Dagger 2 编写2四19个UI测量检验,而且只花了九秒钟就运维成功的。

在那篇作品中,我们会根究怎么着利用Mockito(译者注:Mockito是java编写的二个单元测量检验框架),Dagger
2 去创建急忙可信的Android UI测量试验。借使您正在开首编写Android中的UI
测验大概希望修正原来就有测查验质量量的开辟者,那么那篇小说值得一读。

自己第一回在安卓选拔中采纳UI自动化测量试验是在多年前使用罗布otium(译者注:罗布otium是android中的三个自动化测量试验框架)。笔者感觉测量检验碰到越逼真越好。在最后测量试验中应该表现得仿佛超人日常能够快捷的点击任性多个职位何况并不会报错,对啊?笔者以为mocking测量检验很不佳。为何大家须求在测量试验的时候改换使用的行事?那不是棍骗吗?几个月后大家有了大约九16个测验用例要耗费40分钟去运维起来。它们是那般的不平稳,尽管使用的作用上并未别的不当,日常常有一基本上的概率会运转失败。我们花了汪洋的年华去编写它们,可是那几个测验用例却绝非帮大家找到其它难题。

但正如John Dewey所说,战败是装有诱发意义的。

失利是有启发意义的。智者总能从战败和成功中学到平等多的东西。

作者们的确学到。大家认识到在测验中依附于实际的API
接口是叁个不佳的做法。因为您错过了对回到的多寡结果的决定,你也就不可能对你的测验做事情发生前管理。相当于说互连网错误和表面API接口错误都会引致您的测量试验出错。借使您的wifi出错了,你一定不希望你的测验也会随之出错。你本来希望当时UI测量试验能够成功运转。若是您还依靠外界的API接口那么你完全都以在做集成测验(integration
tests),也就得不到大家愿意的结果。

博客原地点:Android中营造高效可信的UI测量试验译文原链接:Fast and reliable
UI tests on Android翻译:Anthony托

翻译注:假使你关切android构造,那么您料定在此之前看过小鄧子翻译的那篇文章Android应用结构。本篇随笔的正是其最早的著小编Iván
Carballo的又一篇杰出之作。也引入你珍贵github项目Android构造合集以致自己的从零开首搭建android框架体系随笔

Mock测验正式解决之道

(Mocking is the solution)

Mock
测验也正是透过多少个仿照(mock)的靶子去替换贰个实际的对象以有帮衬测量试验。它根本利用于编写单元测量检验,但在UI测量检验中也会极其平价。你能够参见差别的办法去模拟java对象但使用Mockito
确实是二个简短可行的减轻方案。在底下的例证中你能够看看三个模拟的UserApi
类何况stub(译者注:stub,也即“桩”,首要出今后合龙测验的长河中,从上往下的集成时,作为下方程序的代表。能够领略为对章程开展事情发生在此之前的管理,到达改革的效果与利益。下文中不做翻译)了中间的二个措施,因而它总会回来一个顾客名username的静态数组。

class UsersApi {
String[] getUserNames() { }
}
// Create the mock version of a UsersApi class

UsersApi mockApi = Mockito.mock(UsersApi.class);

// Stub the getUserNames() method 

when(mockApi.getUserNames())

.thenReturn(new String[]{"User1", "User2", "User3"});

// The call below will always return an array containing the

// three users named above

mockApi.getUserNames();

假诺你创立了叁个mock对象你需求确认保障应用测验的时候使用的是其一宪章的目的,况兼在运作的时候利用的是真正对象。那也是二个困难所在,假如您的代码营造得并非轻松测量检验(test-friendly)的,替换真实对象的经过会变得老大困难以至是说不容许变成。还要小心的是,你想要模拟的代码必得独立到贰个独自的类里面。举例说,假如您一贯从您的activity中运用HttpURLConnection调用REST
API
进行多少访谈(笔者盼望你不要那样做),
这些操作进程模拟起来也就能优越艰苦。

在测量试验以前思谋一下系统结构,不佳的种类布局往往会引致测验用例和mock测量检验难于编写,mock测量试验也会变得不安宁。

让自家一块儿来探视 Iván Carballo和她的团协会是何等利用Espresso, Mockito
和Dagger 2 编写2肆14个UI测验,並且只花了六分钟就运维成功的。

一个轻易测量试验的布局

A test friendly architecture

塑造多个轻便测量检验的结构有成都百货上千种方式。在那间本身将动用 ribot 中运用的架构(译者注:也正是在开张提到的Android应用构造)作为楷模,你也可以选取那样的布局方式到任何构造中。大家的结构是基于MVP方式,大家决定在UI测验中去模拟(mock)整个Model层,由此大家得以对数据由更加多的操作性,也就能够写出更有价值和有限帮助的测验。

澳门新葡萄京娱乐场 1

MVP架构

DataManager是Model层中独一展露给Presenter层的数据的类,因而为了测量检验Model层我们只要求替换为二个效仿
DataManger即可。

澳门新葡萄京娱乐场,在这里篇文章中,大家会根究怎么样利用Mockito(译者注:Mockito是java编写的叁个单元测量检验框架),Dagger
2 去创建急速可相信的Android UI测量检验。假诺您正在起头编写Android中的UI
测量试验也许希望更改原来就有测量检查验质量量的开辟者,那么那篇小说值得一读。

选拔Dagger注入模拟的DataManager

Using Dagger to inject a mock DataManager

借使大家众所周知了特殊需求效法怎么样目的,那么接下去就该思索在测量检验中怎么样替换真实的指标。大家通过Dagger2
消除这些难点(叁个Android中的信任注入框架),要是您还尚无接触过Dagger
,在持续读书下去以前小编提出您读书使用Dagger2 进行信赖注入【英】
。大家的应用起码含有二个Dagger
的Module和Component。平常被喻为ApplicationComponent
ApplicationModule。你能够在底下见到三个简化版的只提供了DataManger实例的类。当然你也足以选用第二种方法,在DataManager的结构函数上应用@inject注脚。这里自个儿间接提供多个艺术便于精通。(译者注:这里将五个类ApplicationComponent
ApplicationModule写在一块,便于直观领悟)

@Module

public class ApplicationModule {

@Provides

@Singleton

public DataManager provideDataManager() {

return mDataManager;

}

}

@Singleton

@Component(modules = ApplicationModule.class)

public interface ApplicationComponent {

DataManager dataManager();

}

应用的ApplicationComponentApplication类中起头化:

public class MyApplication extends Application {

ApplicationComponent mApplicationComponent;

public ApplicationComponent getComponent() {

if (mApplicationComponent == null) {

mApplicationComponent = DaggerApplicationComponent.builder()

.applicationModule(new ApplicationModule(this))

.build();

}

return mApplicationComponent;

}

// Needed to replace the component with a test specific one

public void setComponent(ApplicationComponent applicationComponent) {

mApplicationComponent = applicationComponent;

}

}

借使您采用过Dagger2,你可能有相似的配置步骤,以往的做法是开创一个test的时候供给动用的Module和Component

@Module

public class TestApplicationModule {

// We provide a mock version of the DataManager using Mockito

@Provides

@Singleton

public DataManager provideDataManager() {

return Mockito.mock(DataManager.class);

}

}

@Singleton

@Component(modules = TestApplicationModule.class)

public interface TestComponent extends ApplicationComponent {

// Empty because extends ApplicationComponent

}

上面的TestApplicationModule接收Mockito提供了仿照的DataManger对象,TestComponentApplicationComponent的世袭类,使用了TestApplicationModule作为module,而不是ApplicationModule。那也就表示要是大家在大家的Application类中开端化TestComponent会动用模拟的DataManager对象。

笔者第二回在安卓应用中应用UI自动化测量试验是在数年前使用罗布otium(译者注:罗布otium是android中的一个自动化测验框架)。小编认为测量试验遭受越逼真越好。在结尾测量试验中应有表现得就如超人经常能够非常的慢的点击任性二个职分何况并不会报错,对吧?小编以为mocking测量检验十分不好。为啥大家要求在测量试验的时候改动使用的一颦一笑?那不是哄骗吗?几个月后大家有了大要上98个测量试验用例要费用40分钟去运营起来。它们是这么的不牢固,固然使用的法力上并从未其余错误,平常常有一只怕的概率会运作退步。大家花了大气的大运去编写它们,不过那个测量试验用例却从不帮大家找到别的难题。

创办JUnit,况兼设定TestComponent

Creating a JUnit rule that sets the TestComponent

为了保险在每一回测量试验前TestComponent被安装到Application类中,大家得以成立JUnit
4 的 TestRule

public class TestComponentRule implements TestRule {

private final TestComponent mTestComponent;

private final Context mContext;

public TestComponentRule(Context context) {

mContext = context;

MyApplication application = (MyApplication) context.getApplicationContext();

mTestComponent = DaggerTestComponent.builder()

.applicationTestModule(new ApplicationTestModule(application))

.build();

}

public DataManager getMockDataManager() {

return mTestComponent.dataManager();

}

@Override

public Statement apply(final Statement base, Description description) {

return new Statement() {

@Override

public void evaluate() throws Throwable {

MyApplication application = (MyApplication) context.getApplicationContext();

// Set the TestComponent before the test runs

application.setComponent(mTestComponent);

base.evaluate();

// Clears the component once the tets finishes so it would use the default one. 

application.setComponent(null);

}

};

}

}

TestComponentRule将会创设TestComponent的实例对象,那也就能覆写apply方法并回到三个新的
Statement,新的Statement会:

1 设定TestComponentApplication类的component对象。
2调用基类的Statementevaluate()办法(那是在test的时候实践)
3
设置Applicationcomponent字段为空,也就让其过来到起来状态。我们可以因此这种情势防守测量检验用例之间的相互成效
透过地方的代码大家得以由此getMockDataManager()格局得到模拟的DataManager目的。那也就允许我们能够给拿走DataManager目的何况stub它的章程。要求注意的是,那独有TestApplicationComponentprovideDataManger主意应用@Singleton声明的时候使得。倘诺它从不被钦定为单例的,那么我们透过getMockDataManager措施获得的实例对象将会分裂于应用使用的实例对象。由此,大家也不容许stub它。

但正如John Dewey所说,战败是有所诱发意义的。

曲折是有启暗中提示义的。智者总能从退步和成功中学到相符多的事物。

编写制定测验用例

Writing the tests

于今大家有Dagger正确的结构,並且TestComponentRule也能够利用了,我们还或者有一件事要做,这正是编制测验用例。大家利用
Espresso编写UI测验。它并非巨细无遗的而是它是叁个比比较快可信赖的Android测量检验框架。在编排测量检验用例早先我们必要一个app去测量检验。假诺大家有三个特别简单的app,从REST
API
中加载客商名,并且出示到RecyclerView上面。那么DataManger将会是下边这几个样子:

public DataManager {

// Loads usernames from a REST API using a Retrofit

public Single<List<String>> loadUsernames() {

return mUsersService.getUsernames();

}

}

loadUsername()措施运用Retrofit和凯雷德xjava 去加载REST API
的数量。它回到的是Single
对象,而且发送一串字符串。
大家也急需三个Activity体现客户名usernamesRecyclerView地点,大家只要这些Activity叫做UsernamesActivity。要是你遵照MVP格局你也许有相应的presenter但为了直观了然,这里不做presenter操作。

到现在我们想要测验那些大致的 Activity有最少多少个状态必要测量试验:

1只要API再次来到贰个一蹴而就的客户名列表数据,那么它们会被显示到列表上边。
2 假使API再次回到空的多寡,那么分界面会彰显“空的列表”
3 即便API 央浼失利,那么分界面会呈现“加载顾客名战败”

上面依次体现三个测验:

@Test

public void usernamesDisplay() {

// Stub the DataManager with a list of three usernames

List<String> expectedUsernames = Arrays.asList("Joe", "Jemma", "Matt");

when(component.getMockDataManager().loadUsernames())

.thenReturn(Single.just(expectedUsernames));

// Start the Activity

main.launchActivity(null);

// Check that the three usernames are displayed

for (Sting username:expectedUsernames) {

onView(withText(username))

.check(matches(isDisplayed()));

}

}

@Test

public void emptyMessageDisplays() {

// Stub an empty list

when(component.getMockDataManager().loadUsernames())

.thenReturn(Single.just(Collections.emptyList()));

// Start the Activity

main.launchActivity(null);

// Check the empty list message displays

onView(withText("Empty list"))

.check(matches(isDisplayed()));

}

@Test

public void errorMessageDisplays() {

// Stub with a Single that emits and error

when(component.getMockDataManager().loadUsernames())

.thenReturn(Single.error(new RuntimeException()));

// Start the Activity

main.launchActivity(null);

// Check the error message displays

onView(withText("Error loading usernames"))

.check(matches(isDisplayed()));

}

}

经过地点的代码,我们运用TestComponentRule 和android
官方测量试验框架提供的ActivityTestRule。ActivityTestRule会让我们从测量试验中运行UsernamesActivity
。注意大家利用 RuleChain 来确定保证
TestComponentRule总是在ActivityTestRule前运营。那也是确定保障TestComponent在任何Activity运转在此以前在Application类中设定好。

你恐怕注意到了多少个测量检验用例据守平等的创设格局:

1 通过when (xxx).thenReturn(yyy)设置前置条件。那是经过stub
loadUsernames(State of Qatar方法达成的。举例,第叁个测验的停放条件是有一个得力的客户名列表。
2 通过main.launchActivity(null)运行activity。
3
通过check(matches(isDisplayed()));反省视图的来得,何况呈现相应后置条件期待的值。

那是三个非常平价的消除方案,它同意你测量检验分化的光景,因为你对全部application的上马状态有所绝没有错调节权。若是您不利用mock来编排上面包车型大巴多少个用例,差不离不大概到达如此的功力因为真实的API接口总会回来相近的数码。

假若您想要查看使用这几个测量试验方法的完整实例,你能够在github查看项目ribot
Android boilerplate 或然 ribot app.

理之当然那一个施工方案也会有一部分毛病。首先在每一个test此前都会stub显得万分麻烦。复杂的界面或然需求在每种测量检验此前有5-十二个stub。将部分stub移到发轫化setup()办法中是可行的但时常分裂的测量检验需求分化的stub。第三个难点是UI测验和暧昧的实现有在着耦合,也就表示一旦您重构DataManager,那么你也急需改过stub。

虽说这么,大家也在ribot
的多少个利用中利用了这几个UI测量试验方法,事实申明那中艺术也会有好处的。举个例子,我们近来的一个Android应用中有2四十五个UI测验能够在八分钟以内运转成功。个中也可以有3八十个Model层和Presenter层的单元测量试验。

好了,笔者盼望那篇小说让您对UI测量检验的心得以至编写更加好的测量检验代码有八个很好的援助。

笔者们真的学到。我们意识到在测验中借助于实际的API
接口是一个糟糕的做法。因为您错过了对回到的数码结果的调整,你也就无法对您的测验做事情发生前处理。也正是说网络错误和表面API接口错误都会以致您的测验出错。即便您的wifi出错了,你一定不指望您的测验也会随着出错。你本来愿意当时UI测验能够成功运营。即使您还借助外部的API接口那么你完全部是在做集成测验(integration
tests),也就得不到我们希望的结果。

(Mocking is the solution)

Mock
测量检验也便是经过三个效仿的对象去替换三个诚恳的目的以造福测量试验。它至关心器重要采纳于编写单元测验,但在UI测量试验中也会特别管用。你可以参照不一致的点子去模拟java对象但选拔Mockito
确实是一个简短实用的设计方案。在底下的事例中你能够看到一个模仿的UserApi
类并且stub(译者注:stub,也即“桩”,首要出现在合龙测量检验的长河中,从上往下的合临时,作为下方程序的代表。可以知晓为对议程开展事前的管理,达到修正的作用。下文中不做翻译)了内部的七个办法,由此它总会回来一个顾客名username的静态数组。

class UsersApi {String[] getUserNames() { }}// Create the mock version of a UsersApi classUsersApi mockApi = Mockito.mock(UsersApi.class);// Stub the getUserNames() method when(mockApi.getUserNames.thenReturn(new String[]{"User1", "User2", "User3"});// The call below will always return an array containing the// three users named abovemockApi.getUserNames();

万一您创设了一个mock对象你须求保证应用测验的时候利用的是那么些宪章的指标,并且在运营的时候利用的是真性对象。那也是二个难题所在,倘诺你的代码塑造得并非便于测量检验(test-friendly)的,替换真实对象的历程会变得要命困难以致是说不大概做到。还要注意的是,你想要模拟的代码必得独立到叁个独立的类里面。比方说,借使您一向从您的activity中运用HttpUV12 VantageLConnection调用REST
API 实行数据访谈(小编期望您不用这么做),
这么些操作进度模拟起来也就能够那一个艰难。

在测量检验早先考虑一下系统结构,不佳的类别结构往往会产生测验用例和mock测验难于编写,mock测量检验也会变得不安静。

A test friendly architecture

营造贰个便于测量试验的构造有广大种方法。在这里处自个儿将动用 ribot 中应用的布局(译者注:也正是在开篇提到的Android应用构造)作为轨范,你也得以接纳那样的结构情势到别的结构中。大家的构造是依照MVP形式,我们决定在UI测验中去模拟整个Model层,因而大家得以对数据由越多的可操作性,也就能够写出更有价值和保证的测量检验。

澳门新葡萄京娱乐场 2MVP架构

DataManager是Model层中有一无二展露给Presenter层的数量的类,由此为了测量试验Model层大家只需求替换为一个模拟的DataManger即可。

Using Dagger to inject a mock DataManager

设若大家显然了索要效法如何目的,那么接下去就该考虑在测验中什么替换真实的对象。大家经过Dagger2
化解那几个标题(二个Android中的注重注入框架),假如您还一贯不接触过Dagger
,在三番若干遍阅读下去早前笔者提出您读书应用Dagger2 进行信赖注入
。我们的利用最少含有一个Dagger
的Module和Component。日常被称得上ApplicationComponent
ApplicationModule。你能够在上面看见三个简化版的只提供了DataManger实例的类。当然你也足以动用第三种艺术,在DataManager的布局函数上选拔@inject评释。这里自身一向提供多个办法便于驾驭。(译者注:这里将多个类ApplicationComponent
ApplicationModule写在联合签字,便于直观了然)

@Modulepublic class ApplicationModule {@Provides@Singletonpublic DataManager provideDataManager() {return mDataManager;}}@Singleton@Component(modules = ApplicationModule.class)public interface ApplicationComponent {DataManager dataManager();}

应用的ApplicationComponentApplication类中初阶化:

public class MyApplication extends Application {ApplicationComponent mApplicationComponent;public ApplicationComponent getComponent() {if (mApplicationComponent == null) {mApplicationComponent = DaggerApplicationComponent.builder().applicationModule(new ApplicationModule.build();}return mApplicationComponent;}// Needed to replace the component with a test specific onepublic void setComponent(ApplicationComponent applicationComponent) {mApplicationComponent = applicationComponent;}}

设若您接受过Dagger2,你也许有同等的计划步骤,今后的做法是创制三个test的时候须要利用的Module和Component

@Modulepublic class TestApplicationModule {// We provide a mock version of the DataManager using Mockito@Provides@Singletonpublic DataManager provideDataManager() {return Mockito.mock(DataManager.class);}}@Singleton@Component(modules = TestApplicationModule.class)public interface TestComponent extends ApplicationComponent {// Empty because extends ApplicationComponent}

上面的TestApplicationModule利用Mockito提供了仿照的DataManger对象,TestComponentApplicationComponent的世襲类,使用了TestApplicationModule作为module,而不是ApplicationModule。这也就意味着一旦大家在我们的Application类中起头化TestComponent会接收模拟的DataManager对象。

Creating a JUnit rule that sets the TestComponent

为了保险在每一遍测量试验前TestComponent被安装到Application类中,我们能够创立JUnit
4 的 TestRule

public class TestComponentRule implements TestRule {private final TestComponent mTestComponent;private final Context mContext;public TestComponentRule(Context context) {mContext = context;MyApplication application = (MyApplication) context.getApplicationContext();mTestComponent = DaggerTestComponent.builder().applicationTestModule(new ApplicationTestModule(application)).build();}public DataManager getMockDataManager() {return mTestComponent.dataManager();}@Overridepublic Statement apply(final Statement base, Description description) {return new Statement() {@Overridepublic void evaluate() throws Throwable {MyApplication application = (MyApplication) context.getApplicationContext();// Set the TestComponent before the test runsapplication.setComponent(mTestComponent);base.evaluate();// Clears the component once the tets finishes so it would use the default one. application.setComponent;}};}}

TestComponentRule将会成立TestComponent的实例对象,这也就能覆写apply方法并回到八个新的
Statement,新的Statement会:1
设定TestComponentApplication类的component对象。2调用基类的Statement
evaluate()办法(那是在test的时候奉行)3
设置Applicationcomponent字段为空,也就让其回复到起来状态。大家能够通过这种措施防止测验用例之间的相互作用通过地点的代码大家能够通过getMockDataManager()艺术赢得模拟的DataManager指标。那也就同意大家能够给拿走DataManager对象而且stub它的方式。须求留意的是,这独有TestApplicationComponentprovideDataManger办法应用@Singleton批注的时候使得。若是它并未有被钦命为单例的,那么大家通过getMockDataManager主意赢得的实例对象将会分化于应用使用的实例对象。因而,大家也不大概stub它。

Writing the tests

近些日子大家有Dagger精确的布署,而且TestComponentRule也得以应用了,大家还也可能有一件事要做,那正是编制测验用例。大家选择Espresso编写UI测量试验。它并不是周密的只是它是二个高速可信赖的Android测量试验框架。在编写测验用例以前大家需求多个app去测验。固然大家有一个极度轻巧的app,从REST
API
中加载客户名,並且突显到RecyclerView上面。那么DataManger将会是上面这么些样子:

public DataManager {// Loads usernames from a REST API using a Retrofitpublic Single<List<String>> loadUsernames() {return mUsersService.getUsernames();}}

loadUsername()艺术应用Retrofit和CRUISERxjava 去加载REST API
的数额。它回到的是Single 对象,并且发送一串字符串。
大家也亟需叁个Activity突显客商名usernamesRecyclerView上边,大家假使那一个Activity叫做UsernamesActivity。如若你依照MVP情势你也是有相应的presenter但为了直观通晓,这里不做presenter操作。今后大家想要测量检验那几个差少之甚少的
Activity有起码多少个状态须求测量试验:1假如API再次回到一个可行的客商名列表数据,那么它们会被显示到列表上边。2
万一API再次来到空的数码,那么分界面会展现“空的列表”3 一旦API
乞求退步,那么分界面会突显“加载顾客名战败”

上面依次展示多个测量检验:

@Testpublic void usernamesDisplay() {// Stub the DataManager with a list of three usernamesList<String> expectedUsernames = Arrays.asList("Joe", "Jemma", "Matt");when(component.getMockDataManager().loadUsernames.thenReturn(Single.just(expectedUsernames));// Start the Activitymain.launchActivity;// Check that the three usernames are displayedfor (Sting username:expectedUsernames) {onView(withText).check(matches(isDisplayed;}}@Testpublic void emptyMessageDisplays() {// Stub an empty listwhen(component.getMockDataManager().loadUsernames.thenReturn(Single.just(Collections.emptyList;// Start the Activitymain.launchActivity;// Check the empty list message displaysonView(withText("Empty list")).check(matches(isDisplayed;}@Testpublic void errorMessageDisplays() {// Stub with a Single that emits and errorwhen(component.getMockDataManager().loadUsernames.thenReturn(Single.error(new RuntimeException;// Start the Activitymain.launchActivity;// Check the error message displaysonView(withText("Error loading usernames")).check(matches(isDisplayed;}}

透过上面包车型客车代码,大家选取TestComponentRule 和android
官方测验框架提供的ActivityTestRule。ActivityTestRule会让大家从测验中运营UsernamesActivity
。注意大家运用 RuleChain 来确定保障
TestComponentRule总是在ActivityTestRule前运转。那也是作保TestComponent在任何Activity运维之前在Application类中设定好。你恐怕注意到了多个测验用例坚守平等的创设立模型式:1
透过when .thenReturn设置前置条件。那是经过stub
loadUsernames(卡塔尔方法实现的。举例,第二个测量试验的内置条件是有二个可行的客户名列表。2
通过main.launchActivity运行activity。3
通过check(matches(isDisplayed;自己钻探视图的呈现,何况彰显相应前置条件期望的值。

那是一个要命管用的解决方案,它同意你测量试验不相同的气象,因为您对全部application的初始状态有所绝对的调整权。固然你不选取mock来编排下面的四个用例,大约不容许达到那样的意义因为实际的API接口总会回来同样的数码。

假定你想要查看使用那一个测量试验方法的一体化实例,你可以在github查看项目ribot
Android boilerplate 或许 ribot app.

当然这几个实施方案也可能有点欠缺。首先在种种test在此之前都会stub显得特别麻烦。复杂的分界面或许须要在每种测验以前有5-14个stub。将部分stub移到开首化setup()措施中是实惠的但平时分化的测验必要差异的stub。第一个难题是UI测量检验和地下的达成成在着耦合,也就象征一旦您重构DataManager,那么你也急需订正stub。

虽说那样,大家也在ribot
的几个应用中动用了那一个UI测量检验方法,事实注明那中艺术也可能有好处的。举个例子,大家近来的叁个Android应用中有2四拾几个UI测量检验能够在八分钟以内运维成功。此中也是有3柒拾七个Model层和Presenter层的单元测量试验。

好了,作者梦想那篇文章让你对UI测验的咀嚼以至编写更加好的测验代码有二个很好的扶植。假让你在编写强健性和轻易测量检验的Android大概IOS
的行使中有如何难点,接待和大家赢得联络?

发表评论

电子邮件地址不会被公开。 必填项已用*标注