Github提供了大量API可供使用，但是大部分时候我们需要的可能只是一个简单的网页（client-side only）的应用，通过js直接调用Github API。

但是由于安全限制，Github并不允许OAuth认证发生在这种应用上。这个时候我们就需要一个帮助我们去获取token的后端，而gatekeeper就可以完成这个任务。

一般的验证流程是这样的

1. 调用Github认证，https://github.com/login/oauth/authorize
2. 在callback页面获取临时code
3. 调用gatekeeper去换取可用token

Gatekeeper是一个node应用，配置信息在config.json中。

Gatekeeper可以很方便的部署到Heroku或者Azure上，对于一般使用，可以做到免费的。…

今天找漫画的时候又想到多多猫了，之前用过一下，当时写插件还是用的记事本在xml中直接编写js，那个体验很差，而且代码测试也很复杂。

今天又需要插件了，自然想换点花样来做，首先考虑的就是使用构建工具来处理大部分问题。这里用的是Gulp。

模板替换和文件生成

我们的目标文件只有一个，那就是index.sited.xml。而这个文件又分了两个部分，首先是xml的声明，包含了一些插件信息，其次是我们的js代码。

首先做的是将这两者分开，分别创建index.xml和index.js文件。

<?xml version="1.0" encoding="utf-8"?>
<sited ver="1" debug="1" engine="32" schema="1">
    <meta guid="<%=app.guid%>">
        <title><%= app.title %></title>
        <intro><%= app.intro %></intro>
        <author><%= app.author %></author>
        <url><%= app.url %></url>
        <encode>utf-8</encode>
        <expr><%= app.expr%></expr>
    </meta>
    <main dtype="1" durl="<%= app.url %>">
        <home>
            <hots cache="1d" title="首页" 

…

客户公司新来了一个CTO，新官上任三把火，他首先盯上了单元测试，他要求只为单个类编写单元测试。所有依赖项都被模拟，简单而言就是单元测试不跨类。

然后客户展示了一段代码，表示按照这个规范很难操作，因为现在有需求要业务重构B类。

class A(val b: B) {

   fun doSomething() {
       b.doSomethingElse()
       b.doSomethingElse2()
       b.doSomethingElse3()
   }
}

我们来简单分析下这个代码和对应的规范：

按照规范A类和B类都有自己的单元测试，然后根据新的业务需求，类B进行重构并隐藏在接口后面，因此从技术上讲，类A可能会根据场景获得不同的行为。

现在的问题是，当我们想要遵循项目的指导方针时，我们还应该重构A的单元测试。之前有一个测试，测试对象是B（当然是被mock的）。现在，当对B的引用消失时，测试将被重构，以验证与这个新接口的调用。

这种情况是在测试重构过程中发生的信息丢失。当在实际系统中存在此类调用时，由于单元测试的纯度，我们不再验证A->B之间的任何通信。

我认为这种情况是对于单元测试纯度的过度要求，进而增加了单元测试的脆弱性。

单元测试的纯度

周围打听下这种纯度要求其实很常见，特别见于新开始建设单元测试的团队，项目领袖对于单元测试对于质量保障有较高的期望，进而导致对于纯度有近乎象牙塔的规范要求，从而导致建设失败。

这种纯度的建设方式可以用于项目初期开荒，一锤子买卖，快速搞定上级下发的KPI，但是对于项目质量保障毫无价值。

对于纯度的争议并不少见，我理解其实更多是对于Unit这个外来词的定义问题，机械的将编程语言的类和方法作为一个Unit就是一个高纯度的要求。

还有一种原因我认为是对于单元测试本质目标的忽略，进而陷入定义的混乱，然而这不是重要的事情。

不可否认关于Unit的确切含义存在一些分歧。但是，单元测试测试的目的并不是为了符合某些任意的定义。目的是检测错误。或者更一般地说：验证代码的行为是否符合预期。

重构时，单元测试应该确保变更没有引入错误或更改行为。因此，测试不应该与测试代码中的实现细节耦合。事实上，应该可以完全重写类的实现，并让测试验证行为是否仍然相同。

因此，从这个角度来看，测试并不关心被测试类是否调用了其他类。这是一个实现细节。事实上，典型的重构是将方法中的一些内部代码提取到一个单独的类中，而这正是测试应该能够验证重构没有改变行为的场景。

还有一个更简单的例子，一个验证Email地址的Utils类，它是一个static方法，签名如下

public static bool isValid(string email)

高纯度的规范要求mock这个方法，你只需要和任何一个最近三个月写过单元测试的研发工程师聊一聊，他就能告诉这个规范是多么愚蠢。

因此，底线是：避免mock（除了外部服务或非确定性输入的情况），并让测试联动尽可能多的类来验证行为。

就我个人而言，我喜欢将“单元”视为“行为单元”——规范中可以独立测试的最小部分。但这只是我的定义。

Mock对脆弱性的影响

其实公正的讲，这个例子本身是特殊的，因为这个例子正好证明了一个中间问题。让我们来回想一下常见的改动情况。

当你做出向后不兼容的改变时，依赖于你所改变的东西就会崩溃。所以，如果你的测试现在报错了，那就太好了——一切都在按预期进行。在这一点上，你有几个选择：…

相比起后端，前端工作的工具生态可以说是相当丰富。如果你工作在一个前后端分离的项目，那么大家各司其职，也没啥问题。

如果项目是一个混合项目，即前后端在一个代码库中，那么使用WebJars就是一个相当有吸引力的选项。WebJars可以帮助我们管理客户端所需的前端依赖，而且使用的是我们熟悉的JVM-base工具，比如Maven，Gradle或者SBT。

通过访问http://www.webjars.org/就可以搜索现有的依赖，并使用它们。如果遇到需要的依赖，但是WebJars并不包含的时候我们就需要自己做点工作的。

总的来说WebJars中依赖的来源总共分三种：

1. NPM
2. Bower
3. Classic

如果依赖来自于NPM或者Bower，那么直接点击Add WebJars，然后输入名字选择版本就可以了。

如果不是通过NPM或者Bower，那么就需要手动去创建ticket等待响应了。

也可以参考贡献指南（http://www.webjars.org/contributing）自己去提交相关的内容物。唯一需要注意的就是路径，内容物的路径应该在META-INF/resources/webjars/

我个人体验来说WebJars其实和Jitpack很像，都是自动系统，都是为了方便管理。…