树莓派 JS 库实现持续集成的“黑科技”

这个阶段在研究树莓派，主要用 Node.js 开发。开源社区有许多非常优秀的树莓派 Node.js 库，但是没有让我觉得特别好用的。因为这些库有的 API 还不错，但是性能不好，有的性能很好，但是 API 不好用。还有一些库没跟上树莓派的硬件升级，使用起来还要自己修改，作者也不处理 pull request，比较麻烦。因此我自己着手重新写一个库 rpio2。

在写库的过程中，自然要充分测试每个 API，个人比较喜欢 TDD / BDD 开发，因此一边开发功能，一边写各个 API 的单元测试。写了单元测试，自然希望在代码提交的过程中能够持续集成，最好是直接使用 travis-ci。

愿望是美好的，但是现实有点残酷。因为树莓派开发不同于其他软件开发，它涉及到硬件，虽然说单元测试可以很简单，主要是测试引脚的同步/异步输入输出和事件（中断）响应，所以开发的时候可以在树莓派环境里跑单元测试，这没有问题，但在集成的时候，我们没有办法让 travis-ci 用树莓派系统环境来跑我们的 test case 吧。这样的话，就需要我们自己实现对底层的 GPIO 的模拟。

实现对 GPIO 的模拟

听起来不错，那就开始干吧！

rpio2 库是基于 node-rpio 的，选择这个库为基础的原因是，node-rpio 又是对 bcm2835 C 语言驱动库的 Node 封装，因为 bcm2835 是用 C 写的针对 Broadcom BCM 2835 处理器（也就是树莓派现在使用的 CPU）的底层驱动，因此它可以达到非常高的性能。

使用了 bcm2835 一个额外的好处是，C 语言驱动库是模块化的函数单元，这对于测试和模拟来说是友好的，因为只需要知道对应的输入输出就可以了。而很多输入输出查规格说明书就可以了。

比如：rpio.open(pin, mode, state)，当 mode 为 INPUT 的时候，如果不传 state 参数，默认的输入电阻是：当 pin <= 8 时，为 PULL_UP，当 8 < pin <= 27 时，为 PULL_DOWN。

这里面比较不好实现的一块是输入信号，因为树莓派可以让 GPIO 接输入设备，而输入设备的输入信号是实时输入的，如果在 JS 里用定时器模拟，并不能做到实时同步输入（因为 JS 是单线程非阻塞模型），所以这里需要考虑多线程，最简单的方法就是用 File API + child_process。

rpio_sim_helper.js

"use strict";

    const fs = require("fs");

    var pin = 0|process.argv[2];
    var timers = process.argv[3].split(",").map(o => 0|o);
    var fileName = "./test/gpio/gpio" + pin;


    function writeAndWait(value, time){
      fs.writeFileSync(fileName, new Buffer([value]));
      return new Promise(function(resolve){
        setTimeout(resolve, time);
      });
    }

    var p = Promise.resolve();

    for(var i = 0; i < timers.length; i += 2){
      p = p.then(((i) => () => writeAndWait(timers[i], timers[i + 1]))(i));
    }

    p.then(function(){
      var content = fs.readFileSync(fileName);
      console.log(content);
    }).catch(err => console.log(err));

上面实现一个简单的程序来开进程写文件，例如，要给 rpio21 引脚模拟发送一段半周期为 100 毫秒的脉冲信号，可以这么用：

node rpio_sim_helper.js 21 1,100,0,100,1,100,0,100...,1,100,0

这样，将它封装进模拟库中：

  helper: function (pin, signal){
        if(config.mapping === "physical"){
          pin = pinMap[pin];
        }    
        return new Promise(function(resolve, reject){
          child_process.exec("node ./test/rpio_sim_helper " + pin + " " + signal, 
            function(err, res){
              if(err) reject(err);
              else resolve(res);
            });
        });

就可以很方便地模拟输入信号了。

对单元测试启用模拟

这很容易实现，一开始，我打算采用 proxyquire 库，这个库可以"代理"一个被测试文件里正常 require 的库，这样我只要将 rpio2 的 require('rpio') 用自己模拟库替代就行了。然而实际使用的时候发现并不行。

主要原因是，使用 proxyquire 还是会先加载 rpio 库，然后才对加载的 rpio 库进行替换，而 rpio 库里面有这样一段代码：

var gpiomap;
    function setup_board()
    {
        var cpuinfo, boardrev, match;

        cpuinfo = fs.readFileSync("/proc/cpuinfo", "ascii", function(err) {
            if (err)
                throw err;
        });

        cpuinfo.toString().split(/\n/).forEach(function (line) {
            match = line.match(/^Revision.*(.{4})/);
            if (match) {
                boardrev = parseInt(match[1], 16);
                return;
            }
        });

        switch (boardrev) {
        case 0x2:
        case 0x3:
            gpiomap = "v1rev1";
            break;
        case 0x4:
        case 0x5:
        case 0x6:
        case 0x7:
        case 0x8:
        case 0x9:
        case 0xd:
        case 0xe:
        case 0xf:
            gpiomap = "v1rev2";
            break;
        case 0x10:
        case 0x12:
        case 0x13:
        case 0x15:
        case 0x92:
        case 0x1041:
        case 0x2082:
            gpiomap = "v2plus";
            break;
        default:
            throw "Unable to determine board revision";
            break;
        }
    }
    setup_board();

上面这段代码通过 /proc/cpuinfo 读取树莓派的版本信息，然而我本地 Mac 环境里并没有 /proc/cpuinfo，因此加载的时候直接报错了。而且这个文件单元测试时没必要加载，直接在测试时加载模拟库就行了。

因此，更简单的方法是测试时，将 rpio2 中的 require('rpio') 直接替换成加载 rpio_sim.js。这一步很多部署工具都可以做，比如 gulp 就是很好的选择。不过我用 babel 插件来实现代码测试覆盖度检查，所以我就直接用 babel 来做了，代码更少，也很方便：

transform_rpio_sim.js

module.exports = function(babel) {
      var t = babel.types;

      return {visitor: {
        CallExpression: function(path){
          if(path.node.callee.name === "require"){
            var module = path.node.arguments[0];
            if(module && module.value === "rpio"){
              module.value = "../rpio_sim.js";
            }
          }
        }
      }}; 
    };

然后我们将这些结合到一起，在 package.json 中编写测试命令：

  "scripts": {
        "test": "babel lib --out-dir test/lib --plugins ../test/transform_rpio_sim.js && mocha test/spec.js",
        "printcov": "script/printcov.js  lib/coverage.lcov lib",
        "test-cov": "babel lib --out-dir test/lib --plugins ../test/transform_rpio_sim.js,transform-coverage && mocha test/spec.js --reporter=mocha-lcov-reporter > lib/coverage.lcov && npm run printcov"
      },

这样就能得到单元测试结果和测试覆盖度结果：

开始集成

接下来我们要在代码提交到 github 时启用 travis-ci 集成，我们和以前一样写一个 .travis.yml 文件：

language: node_js
    node_js:
      - "4"
    sudo: false
    script:
      - "npm run test-cov"
    after_script: "npm install coveralls && cd lib &&  cat coverage.lcov | ../node_modules/coveralls/bin/coveralls.js && cd .."

但是这里有个问题，因为我们的 package.json 文件里有 rpio 的依赖：

  "dependencies": {
        "rpio": "^0.9.11"
      },
      "devDependencies": {
        "consoler": "^0.2.0",
        "chokidar": "^1.6.0",
        "wait-promise": "0.4.1",
        "babel-cli": "6.x.x",
        "babel-runtime": "6.x.x",
        "mocha": "^2.3.4",
        "mocha-lcov-reporter": "^1.2.0",
        "chai": "^3.4.1",
        "babel-plugin-transform-coverage": "^0.1.5"
      },

而这个 rpio 在 travis-ci 的集成环境里并不能编译过去，而且实际上我们测试不需要它。因此，这里需要再写一段 pre-install 脚本将它去掉：

travis_pre_install.sh

#!/bin/sh
    sed -i "/"rpio": .*/d" ./package.json

然后将这个脚本 hook 到 .travis.yml 的命令中去：

language: node_js
    node_js:
      - "4"
    sudo: false
    before_install:
      - sh travis_pre_install.sh 
    script:
      - "npm run test-cov"
    after_script: "npm install coveralls && cd lib &&  cat coverage.lcov | ../node_modules/coveralls/bin/coveralls.js && cd .."

最后，将代码提交到 github，就能完成自动化的持续集成了：

自动的单元测试代码覆盖度检查也是正常的（如果现在测试覆盖度低，请忽略，因为这个库还在更新中~）：

总结

我们要做的事情目标很明确：构建一套适合于树莓派（实际上也适合于其他硬件开发）的纯软件 TDD 方法。在这里我用到了各种技术的组合来实现我的目的，包括：

• 用启进程读写文件的方式来模拟信号输入
• 用 Babel 插件实现模拟库代替真实库
• 用 bash 脚本来实现集成环境的编译预处理

我们会发现，工程师自己实现一个代码库，尤其是涉及工程化的一些工作的时候，知识的广度会很重要。

而且，合理使用各种知识最终解决问题也是一个有趣的过程，不是吗？

有任何问题，欢迎留言区讨论。