从数据流动角度解决测试难题

2017-07-21

上篇讲述了增强逻辑功能测试而改进MVC为MVP，但是这样做可能还不够彻底，现在来讨论另一个纯粹从测试角度设计的框架。

首先我们来明确一下，测试中最核心的东西是什么。当然是数据，我们永远是围绕着数据来的，那么之前一些架构的问题是什么。无论哪个框架，数据的流通都是双向的，当数据流通成为单向了会怎么样呢？

1	in data ==> Module ==> out data

这样我们伪造数据进行测试就会非常方便了。按照这个思想就有了数据单向流通的架构。

数据单向流通的实现

这个概念最早是在web中提出的，应用在React里，官方的方案是Redux。现在swift也提出了一种实现ReSwift。

我在之前写React的时候使用过这种方案，从开发角度来说，这种方案会大大增加开发难度，代码量也会大量增加，而且开发思路也需要从以前的思考方式转换过来。但是如果我们把这个思路转换过来，其实对整个流程是更加简化和分离的。

从测试角度看，我觉得无疑是我知道的最可测的一种框架，甚至可以测试部分视图的逻辑。

那么总的来说，很难说这种结构的好坏，就算不考虑增加的开发时间，也是一种难以给以一种评价的方案。

(Redux/ReSwift)框架介绍

方案的几个核心是：

数据的单向流通
每个视图都可以看做一个状态机
pure function

关于pure function，我就不做太多介绍了，简单的说，就是同一输入必定会有相同的输出，是非常容易测试的一种函数。

首先，我们来看一下官方的架构图。

可以看到，数据流动方向都是朝一个方向进行的。那么下面从每个模块来介绍下，还是以star button为例子。

State

视图状态机，也是所有会更新界面数据保存的地方，可以认为相当于ViewModel。

首先我们star会有以下几种视觉样式

enum StarButtonState {
    case star
    case staring
    case unstar
    case unstaring
}

所以State可以定义为

struct StarState: StateType {
    var state: StarButtonState
    var starCount
}

Action

首先我们定义几种状态机转换的Action类型

struct StarAction: Action { }
struct StaringAction: Action { }
struct UnstarAction: Action { }
struct UnstaringAction: Action { }

以及相应的功能以及状态变更，这里异步请求采用延迟来代表。

func star(id: String) -> Store<StarState>.ActionCreator {
    return { state, store in
        DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
            store.dispatch(StarAction())
        }
        return StaringAction()
    }
}
func unstar(id: String) -> Store<StarState>.ActionCreator {
    return { state, store in
        DispatchQueue.main.asyncAfter(deadline: .now() + 1) {
            store.dispatch(UnstarAction())
        }
        return UnstaringAction()
    }
}

View

视图层其实很简单，只需要根据State的不同来更新就可以了。注意的是，更新都是无状态的，和上一个状态无关，所以view层是个无状态层。

class StarButton: UIButton, StoreSubscriber {

    let store = Store<StarState>(reducer: starReducer, state: nil)

    override init(frame: CGRect) {
        super.init(frame: frame)

        self.store.subscribe(self)
    }

    func newState(state: StarState) {
        // update UI
    }
}

Reducer

状态转换器，唯一可以更新State的地方。

func starReducer(action: Action, state: StarState?) -> StarState {
    var state = state ?? StarState(state: .star, starCount: 0)

    switch action {
    case _ as StarAction:
        state.state = .star
        state.starCount += 1

    case _ as StaringAction:
        state.state = .staring

    case _ as UnstarAction:
        state.state = .unstar
        state.starCount -= 1

    case _ as UnstaringAction:
        state.state = .unstaring

    default:
        break
    }

    return state
}

数据传递

那么最重要的就是数据如何传递的了。首先要明确的是每个模块能够修改的，或者说是传递的，只能是下个模块。

比如，用户star button触发了一个事件：

func onButton(sender: StarButton) {
    if (store.state.state == .unstar) {
        store.dispatch(star(id: id))
    }
    else if (store.state.state == .star) {
        store.dispatch(unstar(id: id))
    }
}

此时会创建Action，也就是将view事件转换为Action。然后会传递到store中，store会调用Reducer进行处理。Reducer更新state之后又会触发store的subscribe事件，回到view的func newState(state: StarState)。

View (User Event)
==(create)==> ActionCreator/Action
==(dispatch)==> Store <--(Update State)--> Reducer
                  \==(subscribe)==> View (newState)

大概的一个流程就是这样了。

接下来说说这样做的模块化的优势。

模块化和测试性

首先，我们需要有函数式编程的概念，函数也是一等公民，所以ActionCreator和Reducer都是独立的模块。

作为使用者，我们在不需要像MVC一样知道这些api所代表的操作功能，相对应的，我们需要去了解一个模块的动作（Action），比如以上例子就是

1 2	func star(id: String) func unstar(id: String)

这样的划分比MVC要友好的多，真正的把逻辑功能从原本的C中分离开。需要触发这个行为也非常简单store.dispatch(star(id: id))。相比MVP，行为更加的独立，每个行为之间完全没有联系，也不会产生干扰影响。同时因为每个行为的独立性，可复用程度也就越高。

Reducer则代表了view层的更新，也可以非常明确的知道每个状态的变更发生了什么。相比其他模式，将界面更新完全交给view或者Controller，Reducer是最明确也是最清晰的。同时Reducer也是独立的，可以替换的。

对于UIkit层面我们无法单元测试，所以测试的主要部分是Action和Reducer。这两个模块可以说都是pure function或者在某些条件下是pure function的，所以测试也非常的简单。

对比

和这个模式比较像的有状态机模式和Reactive。

状态机模式也是实现对应功能，以及对应状态，然后通过子类化的方式去实现Reducer的功能。

Reactive则比较像ActionCreator，只是Reactive返回的是信号量。

使用场景

从上面可以看出这是一套非常优秀的模块划分方案，但同时也会大大增加代码量，而且需要改变以前的思维模式。而对于目前国内的现状来看，很难有这么多时间和精力让整个项目都使用这种模式。

但是这种模式的特点也非常的明显，在处理比较复杂的交互行为，并且存在较多的视图状态的时候，会是一种比较好的方案。比如视频播放界面。

所以个人认为，在一些简单的场景下并不需要使用该方案，但是在一些复杂的交互页面，而且又非常想要引入单元测试的场景，可以酌情考虑下这种方案。这种方案要求人们的思维方式的改变，需要有一定的函数式编程的概念。

虽然不一定会直接使用ReSwift，但是这种思想有很多值得借鉴的地方，利用这种思想做出类似的效果，以便达到可以容易进行白盒测试的目的。

最后

以上虽然说不会全部使用该方案，但也可以部分使用。比如独立的小模块，亦或是app层面的一些东西。下次可以讨论下app层面如何来利用单向数据流来简化流程。