测验你的前端代码,iOS单元测量检验和UI自动化测

测试你的前端代码 – part1(介绍篇)

2017/04/21 · 基础技术 · 测试

原文出处: Gil Tayar   译文出处:胡子大哈   

图片 1

最近我的一个刚刚接触前端开发的朋友,问我如何测试他的 app。当时是电话交流的,大家都知道测试是一个繁杂的知识体系,不可能通过电话说清楚,不过我也跟他保证了要给他发一份“测试指引”。

然后我通过 Google 搜索测试相关的主题,找到了非常多的文章,但是我对于这些文章所介绍的深度并不满意。另外对于一个前端新手来说,我找不到一个综合性的教程能让前端小白逐步深入地进行应用测试。我想要找的是理论结合实践的前端测试教程。

所以我决定自己写一个前端测试系列。这里就是这一系列的开始。

测试你的前端代码 – part4(集成测试)

2017/06/05 · 基础技术 · 测试

原文出处: Gil Tayar   译文出处:胡子大哈   

上一篇文章《测试你的前端代码 – part3(端到端测试)》中,我介绍了关于端到端测试的基本知识,从本文介绍集成测试(Integration Testing)。

参考文章 : http://chriszou.com/2016/06/07/android-unit-testing-everything-you-need-to-know.html

第一部分:单元测试

什么是测试?

我把测试定义成:是一段检测你的应用代码(也叫“生产代码”)是否按预期执行的代码。有些人称之为 TDD(Test-Driven Development 或者 Test-Driven Design),但是 TDD是一种特定的测试方法,它先写测试,然后用测试来驱动产品的设计和实现。

坦率地讲,我认为在生产代码完成之前写测试代码,还是在完成之后写测试代码并不重要。只要你写了足够多的测试样例测试你的生产代码,直到你对你的生产代码已经足够有信心就好。但是有很多人(包括我所尊敬的人)认为顺序很重要,这里我持自己的保留意见。

一个不好的现象是现在工业界已经把测试和 TDD 的概念混淆在一起,这样对于写生产代码的开发者所写的测试代码,就没有一个标准术语来称呼了。我倾向于叫它开发测试,或者普通测试。如果你对 “TDD vs 普通测试” 的讨论感兴趣,可以看这里,不过我建议你把我这个系列博文看完再参与讨论。

集成测试

我们已经看过了“测试光谱”中的两种测试:单元测试和端到端测试。实际工作中的测试经常是介于这两种测试之间的,包括我在内的大多数人通常把这种测试叫做集成测试。

什么是单元测试

简单的说: 单元测试是为了测试某一个代码单元而写的测试代码;

什么叫“一个代码单元”呢?是一个模块、还是一个类、还是一个方法(函数)呢?

在面向对象编程中,是为了测试某一个类的某一个方法能否正常工作,而写的测试代码。

  • 单元测试不是集成测试
    这里需要强调一个观念,那就是单元测试只是测试一个方法单元,它不是测试一整个流程。

  • 两种函数(方法),两种不同的测试方式
    一个类的方法可以分为两种,一种是有返回值的,另一种是没有返回值的。

1、单元测试简介

为什么测试?

我不打算在这里讨论为什么要进行测试。如果你不想写测试,那你就不写。不过你需要手动地一遍又一遍地测试你的 web 应用,这简直糟透了。那些讨厌的 bug,会不断地过来讨扰你。把这样的代码部署到生产环境,将是你噩梦的开始。

所以,我不打算深入讨论为什么要进行测试。

关于术语

和许多 TDD 爱好者聊过以后,我了解了他们对“集成测试”这个词有一些不同的理解。他们认为集成测试是测试代码边界,即代码对外的接口部分。

比如他们代码中有 Ajax,localStorage 或者 IndexedDB 操作,那其代码就不能做单元测试,这时他们会把这些代码打包成接口,然后在做单元测试的时候 mock 这些接口。当真正测试这些接口的时候才称作“集成测试”。从这个角度来说,“集成测试”就是在纯的单元测试以外,测试与外部“真实世界”相关的代码。

而我和其他一些人则倾向于认为“集成测试”是将两个或多个单元测试综合起来进行测试的一种方法。通过接口把与外部相关的代码打包到一起,再 mock,只是其中的一种实现方式。

我的观点里,决定是否使用真实场景的 Ajax 或者其他 I/O 操作进行集成测试(即不使用 mock),取决于是否能够保证测试速度足够快,并且能够稳定测试(不发生 flaky 的情况)。如果可以确定这样的话,那尽管用真实场景进行集成测试就好了。不过如果很慢或者发生不稳定测试的情况,那还是用 mock 会好一些。

在我们的例子中,计算器应用唯一的真实 I/O 就是操作 DOM 了,没有 Ajax 调用,所以不存在上面的问题。

为什么写单元测试

  • 首先跑一次单元测试总比运行一次app快
  • 写完一部分功能独立的代码,就能立刻看到他们是不是正确的
  • 减少大部分手工测试
  • 更快的发现bug
  • 并发现更多的bug
  • 测试驱动开发(TDD) ,提高开发效率
  • 觉的没有时间写测试代码?

   在计算机编程中,单元测试(又称为模块测试, Unit Testing)是针对程序模块(软件设计的最小单位)来进行正确性检验的测试工作。程序单元是应用的最小可测试部件。在过程化编程中,一个单元就是单个程序、函数、过程等;对于面向对象编程,最小单元就是方法,包括基类(超类)、抽象类、派生类(子类)中的方法

测试的类型

另外一个新手学习测试很容易有疑问的地方是:有很多种不同的测试类型。如果你提前做了点功课的话,你可能听说过(这里列出部分测试方法列表):单元测试、验收测试、集成测试、端到端测试、组件测试和服务测试。

更糟的是,当谈到了上面某一个具体的测试时,不同的人又有不同的理解。

这里再次说明我的观点,我认为叫什么名字都不重要,因为各种测试的定义都不难理解。所有的测试都分布于“测试光谱”中,光谱的一头是单元测试,另一头是端到端测试(后面统一称为 E2E 测试)。

mock DOM

这就引出了一个问题:在集成测试中是否需要 mock DOM?重新思考一下上面我说的标准,使用真实 DOM 是否会使测试变慢呢,答案是会的。使用真实 DOM 意味着要用浏览器,用浏览器意味着测试速度变慢,测试变的不稳定。

那么是不是要么只能尽量把操作 DOM 的代码分离出来,要么只能使用端到端测试了呢?其实这两种方法都不好。还有另一种解决方案:jsdom。一个非常棒的包,用它自己的话说:这是在 NodeJS 中实现的 DOM。

它确实比较好用,可以运行在 Node 环境下。使用 JSDom,你可以不把 DOM 当做 I/O 操作。这一点非常重要,因为要把 DOM 操作从前端代码中分离出来非常困难(实际工作中几乎不可能完全分离)。我猜 JSDom 的诞生就是因为这个原因:使得在 Node 中也可以运行前端测试。

我们来看一下它的工作原理,和往常一样,需要有初始化代码和测试代码。这次我们先看测试代码。不过正式看代码之前请先接受我的歉意。

怎么写单元测试

    通常来说,程序员每修改一次程序就会进行最少一次单元测试,在编写程序的过程中前后很可能要进行多次单元测试,以证实程序达到软件规格书(en:Specification)要求的工作目标,没有程序错误.

测试光谱

歉意

这一部分是这个测试系列文章中唯一使用指定框架的部分,这部分使用的框架是 React。选择 React 并不是因为它是最好的框架,我坚定地认为没有所谓最好的框架,我甚至认为对于指定的场景也没有最好的框架。我相信的是对于个人来讲,只有最合适,用着最顺手的框架。

而我使用着最顺手的框架就是 React,所以接下来的代码都是 React 代码。但是这里依然说明一下,前端集成测试的 jsdom 解决方案可以适用于所有的主流框架。

ok,现在回到正题。

我们先不说测试代码怎么写,先搞清楚流程

刚才说了,单元测试是为了测试某一个类的某一个方法能否正常工作,而写的测试代码,
那我们写单元测试代码,就是给每一个java代码类的public方法写对应的测试代码;
那么非public方法怎么办呢, 一般来说,是不做处理的, 非public方法通常是类的内部实现细节,我们一般只关心public方法的的输入和输出;

    一个重要的概念:TDD(Test-Driven Development),即测试驱动开发,该模式要求开发者在编写某个功能的代码之前先将其测试代码写好,然后编写实现代码并进行测试,从而保证实现的代码不会出现问题。因此整个项目的开发进度将由测试来驱动,这有助于开发出高质量而又正确的代码,实现敏捷开发

光谱的一端——单元测试

顾名思义,代码以单元为单位进行测试。那么什么是单元呢?这就不同的编程语言的定义不一样了。它可以是一个函数、一个模块、一个包或者一个类,甚至是一个对象(比如 JavaScript 和 Scala 语言)。在 JavaScript 中,通常是以类或者模块作为一个单元。

以单元进行测试很重要的一点是其测试是独立的。对于一些场景这种测试非常适合,比如算法、某些功能性函数(如字符串中有多少字符)和包含一组验证性功能的类等场景。

这些场景下进行独立的单元测试非常容易,因为他们不依赖于其他单元。但是假设一个单元依赖于其他单元怎么办?可以有两种做法:两个单元一起测试,或者 mock 另一个单元。

什么是 mock?下面我们举例来解释:

假设一个模块是一个单元,模块中包含了 writeSumToFile 这个函数,函数接收两个数字参数,并把他们的和写入文件中。

这里注意,这个模块自己并没有做写文件操作。写文件操作是在另一个单元 fileSumWriter 中做的。

那么为了测试第一个单元,我们既可以传一个真实的 fileSumWriter 进来,也可以模拟(mock)一个写文件操作(并不用真的实现写操作)。

如果我们传递一个 mock 到这个函数,那么这个单元测试,当然可以叫做“单元测试”,因为没有涉及到其他单元。但是如果两个单元一起测试,那么可能就有人说你这并不是单元测试了。

还是那句话,我不关心这到底应该叫什么。

使用 Jsdom

JavaScript

const React = require('react') const e = React.createElement const ReactDom = require('react-dom') const CalculatorApp = require('../../lib/calculator-app') ... describe('calculator app component', function () { ... it('should work', function () { ReactDom.render(e(CalculatorApp), document.getElementById('container')) const displayElement = document.querySelector('.display') expect(displayElement.textContent).to.equal('0')

1
2
3
4
5
6
7
8
9
10
11
12
13
14
const React = require('react')
const e = React.createElement
const ReactDom = require('react-dom')
const CalculatorApp = require('../../lib/calculator-app')
    ...
describe('calculator app component', function () {
        ...
    it('should work', function () {
        ReactDom.render(e(CalculatorApp), document.getElementById('container'))
        const displayElement = document.querySelector('.display')
        expect(displayElement.textContent).to.equal('0')

注意看第 10 – 14 行,首先 render 了 CalculatorApp 组件,这个操作同时也 render 了 DisplayKeypad。第 12 和 14 行测试了 DOM 中计算器的显示是否是 0(初始化状态下)。

上面的代码是可以运行在 Node 下的,注意到里面用的是 document。我第一次使用它的时候特别惊讶。全局变量 document 是一个浏览器变量,竟然可以使用在 NodeJS 中。在这简单的几行代码背后有着大量的代码支撑着,这些 jsdom 代码几乎是完美地实现了浏览器的功能。所以这里我要感谢 Domenic Denicola, Elijah Insua 和为这个工具包做过贡献的人们。

图片 2

第 10 行中也使用了 document(调用 ReactDom 来渲染组件),在 ReactDom 经常会使用它。那么在哪里创建的这些全局变量呢?在测试中创建的,见下面代码:

JavaScript

before(function () { global.document = jsdom(`<!doctype html><html><body><div id="container"/></div></body></html>`) global.window = document.defaultView }) after(function () { delete global.window delete global.document })

1
2
3
4
5
6
7
8
9
before(function () {
        global.document = jsdom(`<!doctype html><html><body><div id="container"/></div></body></html>`)
        global.window = document.defaultView
      })
 
    after(function () {
        delete global.window
        delete global.document
      })

代码中创建了一个简单的 document,把我们的组件挂在一个简易 div 上。同时还创建了一个 window,其实我们并不需要它,但是 React 需要。最后在 after 中清理全局变量。

documentwindow 一定要设置成全局的吗?滥用全局变量不论理论和实践的角度都不是个好习惯。如果它们是全局的,那这个集成测试就不能和其他的集成测试并行运行(这里对 ava 的用户表示抱歉),因为它们会互相覆写全局变量,导致结果错误。

然而,它们必须要设置成全局的,React 和 ReactDOM 要求 documentwindow 是全局的,不接受把他们以参数的形式传递。或许等 React fiber 出来就可以了?也许吧,不过现在我们还必须要把 documentwindow 设置成全局的。

一般来说写单元测试代码分为三个部分

  • 准备工作 : 一般先要new出你要的测试的类的对象
  • 执行操作 : 然后写测试代码
  • 验证结果 : 得到验证结果,看是否达到预期

注意事项: 单元测试不会接触到数据库,不会接触到网络,不会接触到一些复杂的外部环境,如果有的话,那可能是你测试的方式有误,测试的粒度不够“单元”

2、单元测试工具

光谱的另一端——端到端测试

上面介绍了以一个单元为单位的测试。现在介绍端到端测试——测试整个应用。测试过程中,应用的所有配置会设置成和生产环境一样,应用中的一切都会被测试到。

这两个是“测试光谱”的两端。上面提到的其他测试方法,都是分布在这两个极端中间。他们的基本思路是逐步扩大测试范围,被测试的代码越来越多,mock 的代码越来越少。

很多人把这两个极端测试中间的部分叫做“集成测试”,但是对于 TDD 崇尚者们来说,集成测试是另一个完全不同的概念。在本系列文章中我将会使用这个概念模糊的名字——集成测试,具体说来就是:测试多个单元,但不是测试全部单元。

事件处理

剩下的测试代码怎么写呢,看下面代码:

JavaScript

ReactDom.render(e(CalculatorApp), document.getElementById('container')) const displayElement = document.querySelector('.display') expect(displayElement.textContent).to.equal('0') const digit4Element = document.querySelector('.digit-4') const digit2Element = document.querySelector('.digit-2') const operatorMultiply = document.querySelector('.operator-multiply') const operatorEquals = document.querySelector('.operator-equals') digit4Element.click() digit2Element.click() operatorMultiply.click() digit2Element.click() operatorEquals.click() expect(displayElement.textContent).to.equal('84')

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
ReactDom.render(e(CalculatorApp), document.getElementById('container'))
const displayElement = document.querySelector('.display')
expect(displayElement.textContent).to.equal('0')
const digit4Element = document.querySelector('.digit-4')
const digit2Element = document.querySelector('.digit-2')
const operatorMultiply = document.querySelector('.operator-multiply')
const operatorEquals = document.querySelector('.operator-equals')
digit4Element.click()
digit2Element.click()
operatorMultiply.click()
digit2Element.click()
operatorEquals.click()
expect(displayElement.textContent).to.equal('84')

测试中主要实现的是用户点击 “42 * 2 = ”,结果应该是输出 “84”。这里获取 element 使用的是广为人知的 querySelector 函数,然后调用 click 点击。还可以创建事件,然后手动调度,见下面代码:

JavaScript

var ev = new Event("keyup", ...); document.dispatchEvent(ev);

1
2
var ev = new Event("keyup", ...);
document.dispatchEvent(ev);

这里有内置的 click 函数,所以我们直接使用就好了。就是这么简单!

机智的你可能已经发现了,这个测试和前面的端到端测试其实是一样的。但是注意这个测试要快 10 倍以上,并且实际上它是同步的,代码也更容易写,可读性也更好。

但是如果都一样的话,那需要继承测试干嘛?因为这是个示例项目嘛,并不是实际项目。这个项目里面只有两个组件,所以端到端测试和继承测试是一样的。如果是在实际项目中,端到端测试可能包含了上百个单元,而继承测试只包含少量单元,比如包含 10 个单元。所以实际项目中只有几个端到端测试,而可能包含了上百个继承测试。

刚才上面说到

一个类的方法可以分为两种,一种是有返回值的,另一种是没有返回值的。

   OCUnit(Xcode自带的单元测试)

结语

那么你的测试到底在什么测试层级上呢?很多人说有一个测试金字塔——大量的单元测试,少部分的集成测试,非常小部分的端到端测试。但是我不想讨论这些,这个系列文章我希望讨论的是如何对前端代码进行单元测试、集成测试和端到端测试。

接下来的文章,第一篇将会介绍前端单元测试,第二篇会介绍端到端测试,第三篇会介绍集成测试。

应这个系列的博文需要,我写了一个小 app——计算器——我用它来展示如何进行不同类型的测试。你可以在这里获取它的源代码,不过请注意现在还不完整,当整个系列博文完成的时才算完整。

1 赞 2 收藏 评论

图片 3

总结

本文中主要介绍了什么:

  • 介绍了使用 jsdom 方便地创建全局变量 documentwindow
  • 介绍了如何使用 jsdom 测试应用;
  • 介绍了,测试就是这么简单^_^。

    1 赞 收藏 评论

图片 4

先说有返回值的

        1、简介:Xcode自带的单元测试工具

JUnit单元测试框架的使用

单元测试,一般都会用到一个或多个单元测试框架,在这里,我们介绍一下JUnit4这个测试框架。这是Java界用的最广泛,也是最基础的一个框架,其他的很多框架都是基于或兼容JUnit4的。

        2、测试方法:

为什么要使用单元测试框架

首先你也可以不用测试框架, 手工写测试代码, java 中可以使用main方法执行测试代码,你可以自己写测试代码,然后执行

             1)特点: 以test开头,没有返回值,没有参数

有下面的这段代码需要进行测试

   public Boolean loginApp(String name){
        if (name == "123456") {
            return true;
        }else {
            return false;
        }
    }

              2)执行顺序:字典序排序(数字>小写字母>大写字母)

我们看看在不使用JUnit测试框架的情况下怎么怎么测试

public static void main(String[] args) {
        LoginPersenter loginPersenter = new LoginPersenter();
        Boolean aBoolean = loginPersenter.loginApp("123456");
        if(aBoolean == true) {
            System.out.println("登录成功了");
        } else {
            System.out.println("登录失败了");
        }
    }

             3)系统方法:

那么我们使用JUnit测试框架的情况下

     @Test
    public void testAppLogin()  throws Exception{
        LoginPersenter loginPersenter = new LoginPersenter();
        Boolean aBoolean = loginPersenter.loginApp("123456");
         assertTrue(aBoolean);
    }

每一个被测试的方法,写一个对应的测试方法, 通过@Test注解来标识

                 1)setUp:所有测试方法执行之前都会执行这个方法

先来看看JUnit注解

注解 描述
@Test public void method() 简单说就是用这个注解的代表的是一个测试用例
@Before public void method() Before注释表示,该方法必须在类中的每个测试之前执行,以便执行测试某些必要的先决条件。
@BeforeClass public static void method() BeforeClass注释指出这是附着在静态方法必须执行一次并在类的所有测试之前。发生这种情况时一般是测试计算共享配置方法(如连接到数据库)。
@After public void method() After 注释指示,该方法在执行每项测试后执行(如执行每一个测试后重置某些变量,删除临时变量等)
@AfterClass public static void method() 当需要执行所有的测试在JUnit测试用例类后执行,AfterClass注解可以使用以清理建立方法,(从数据库如断开连接)。注意:附有此批注(类似于BeforeClass)的方法必须定义为静态。
@Ignore public static void method() 当想暂时禁用特定的测试执行可以使用忽略注释。每个被注解为@Ignore的方法将不被执行。

                 2)tearDown:所有测试方法执行之后都会执行这个方法

然后看看JUnit断言

断言 描述
void assertEquals([String message], expected value, actual value) 断言两个值相等。值可能是类型有 int, short, long, byte, char or java.lang.Object. 第一个参数是一个可选的字符串消息
void assertTrue([String message], boolean condition) 断言一个条件为真
void assertFalse([String message],boolean condition) 断言一个条件为假
void assertNotNull([String message], java.lang.Object object) 断言一个对象不为空(null)
void assertNull([String message], java.lang.Object object) 断言一个对象为空(null)
void assertSame([String message], java.lang.Object expected, java.lang.Object actual) 断言,两个对象引用相同的对象
void assertNotSame([String message], java.lang.Object unexpected, java.lang.Object actual) 断言,两个对象不是引用同一个对象
void assertArrayEquals([String message], expectedArray, resultArray) 断言预期数组和结果数组相等。数组的类型可能是 int, long, short, char, byte or java.lang.Object.
fail() 让测试方法失败

                 3)testExample:一个测试用例,里面可以写测试代码

看完这些东西 ,我们写个代码应用一下

先看一下等待测试的代码

package com.zhiguo.dagger2test;

/**
 * Created by TiaoPi on 2017/11/20.
 */

public class JUnitTest {

    public int testAdd(int a ,int b){
        return a   b;
    }

    public Boolean testEquals(int a ,int b){
        if (a == b) {
            return true;
        }else {
            return false;
        }
    }

}

然后看一下测试代码

@RunWith(AndroidJUnit4.class)
public class ExampleInstrumentedTest {

    JUnitTest jUnitTest;
    int testAddNum ;

    @Before
    public void setup() {
        jUnitTest = new JUnitTest();
        testAddNum = 2;
    }

    @After
    public void executedAfterEach(){
        testAddNum = 2;
    }

    @Test
    public void testAdd() throws Exception{
        int testAdd = jUnitTest.testAdd(1, 2);
        assertEquals(testAddNum   1,testAdd);
//        assertEquals("测试得到的结果是不是"  testAddNum   1 ,testAddNum   1,testAdd);
    }

    @Test
    public void testAdd2() throws Exception{
        int testAdd = jUnitTest.testAdd(2, 2);
        assertEquals(testAddNum   2,testAdd);
//        assertEquals("测试得到的结果是不是"  testAddNum   2 ,testAddNum   2,testAdd);
    }


    @Test
    public void testEquals()  throws Exception{
        Boolean aBoolean = jUnitTest.testEquals(1, 1);
        assertTrue(aBoolean);
//        assertTrue("测试得到的结果不是true",aBoolean);
    }

    @Test
    @Ignore("不让testIgnore方法执行")
    public void testIgnore() {
    }

}

开始执行

图片 5

1f844e5d-4aeb-497f-989a-4693f8d05b56.png

执行完成后,没有问题的情况下

图片 6

d69996ec-0b6b-46e6-9e04-077554724a93.png

                 4)testPerformanceExample:性能测试,测试一段代码执行时常

我们搞几个问题出来

图片 7

4964d84f-e022-4ab1-93e6-40b87ffd8317.png

       3、断言宏:

其他的功能介绍

                框架中包含了18个断言宏,用来判断测试成功或失败

Ignore一些测试方法

让JUnit忽略某些方法,让它在跑所有测试方法的时候不要跑这个测试方法。要达到这个目的也很简单,只需要在要被忽略的测试方法前面加上@Ignore就可以了

    @Test
    @Ignore("不让testIgnore方法执行")
    public void testIgnore() {
    }

图片 8

13592a67-cae4-4a21-ae6f-8ca32e656590.png

      4、测试用例Demo地址:

验证方法会抛出某些异常

有的时候,抛出异常是才能让一个方法正常运行。

比如我们现在有这样一段代码

 public int testExpected (int a){
        if (a == 1) throw new  IllegalArgumentException("这个值不能是1");
        return a;
    }

进行测试

    @Test(expected = IllegalArgumentException.class)
    public void testExpected (){
        jUnitTest.testExpected(1);
    }

当然啦,如果正确的抛出异常是说明代码没问题, 只有抛出异常的时候才会报错

   OCMock(提供模拟条件)

       1、介绍:

接下来 我们考虑测试没有返回值的方法

        测试过程中,对于一些不容易构造或不容易获取的对象,此时你可以创建一个虚拟的对象(mockobject)来完成测试其实现思想就是根据要mock的对象的class来创建一个对应的对象,并且设置好该对象的属性和调用预定方法后的动作(例如返回一个值,调用代码块,发送消息等等),然后将其记录到一个数组中,接下来开发者主动调用该方法,最后做一个verify(验证),从而判断该方法是否被调用,或者调用过程中是否抛出异常等,宗旨就是没有条件,自行创造条件。

      2、应用场景:

            1)可能要尝试100此才能返回一个NSError,通过mockObject可以自行创建一个NSError对象来测试出错时是否符合预期

            2)服务器是内网,在外地或者外网访问不了,可以创建一个虚拟服务器,并返回一些你指定的数据,从而绕过服务器

            3)访问一个数据库,但是访问开销很大,这时可以虚拟一个数据库,并且返回一个自行定制的数据

     3、添加到工程中

    4、测试用例Demo地址:

   GHUnit(带有GUI的开源测试框架)

          1、简介:带有GUI的单元测试框架

          2、断言宏:开头都以GHAssert开头

          3、可视化:

可以通过可视化的界面看到那些测试用例成功还是失败,点击失

败的测试用例还可以看到终端输出的日志,查看错误的原因

4、配置

5、Demo地址:

UI自动化测试:

    1、Automation:用于做UI自动化测试

    2、通过JS语言实现,可以自己编辑一个JS文件然后加载进来并执行对应的操作。

    3、同事也支持自动录制,录制的同时会自动生成JS脚本,这个脚本也可以保存成JS脚本文件。

    4、Demo地址:

总结

单元测试非常适合用来做APP的逻辑以及网络接口的测试

通过UI自动化测试以前旧功能或者小的改动

版本代码完成后根据测试人员编写的测试用例进行充分自测

本文由星彩网app下载发布于前端技术,转载请注明出处:测验你的前端代码,iOS单元测量检验和UI自动化测

TAG标签:
Ctrl+D 将本页面保存为书签,全面了解最新资讯,方便快捷。