摘要：對于集成測試，直接模擬實(shí)際的環(huán)境，再加上合適的，目前看來也還不錯。這里給出兩個例子集成測試單元測試都是基于寫的，各位可以體驗(yàn)其酸爽度。好啦，本期內(nèi)容就此結(jié)束，請保持關(guān)注，期待下期繼續(xù)本系列其他文章入坑須知入坑須知

隨著Vert.x進(jìn)化到3.5.0，本系列也迎來了新篇章。

對于CORS，搞Web開發(fā)（不論你是前端，還是后端）的同志應(yīng)該不陌生，尤其是如今微服務(wù)盛行的時代，CORS更是最常用的配置項(xiàng)之一。假若你對此還有一點(diǎn)點(diǎn)的疑問，不用問，你已經(jīng)落伍了！

Vert.x很早就支持了CORS，但到了3.5.0，出于安全性上的考慮，它增加了一個限制：

當(dāng)allowedOriginPattern為“*”時，allowCredentials不允許為“true”。

這個限制其實(shí)起源自協(xié)議的限制：

The string "*" cannot be used for a resource that supports credentials.The string "*" cannot be used for a resource that supports credentials.

即：Access-Control-Allow-Origin為“*”時，Access-Control-Allow-Credentials會被忽略，Credentials信息（一般是Cookie）也不會被user-agent發(fā)送。大家可以參考這篇文章（英文原版）了解如何安全地設(shè)置各個header。

在3.5.0時，當(dāng)allowedOriginPattern為“*”和allowCredentials為“true”時，Vert.x會產(chǎn)生一個異常，若不處理會導(dǎo)致Verticle不能正常啟動。在之前的版本中，不會出現(xiàn)這種情況。

斷路器是個好東東，強(qiáng)烈建議在框架設(shè)計(jì)上就考慮它，以避免粗心的開發(fā)者寫的代碼擾亂其他好代碼。在我寫dgate和dfx時，對所有對外暴露的服務(wù)也都強(qiáng)加了這個限制。

既然CB這么好，是不是動過將其應(yīng)用到普通Handler上的念頭？不過由于Vert.x CB的文檔示例中給出的都是清一色的HTTP請求的例子，要想將CB推而廣之應(yīng)用到普通的Handler上還得費(fèi)點(diǎn)氣力。

在dfx中我寫了一個工具類，對此需求進(jìn)行了封裝：

public static void withCircuitBreaker(Vertx vertx, CircuitBreaker circuitBreaker
        , Accessible accessible, Map params, Handler

它的使用很簡單：

Utils.withCircuitBreaker(vertx, circuitBreaker, accessible, body.getMap()
               , result -> Utils.fireJsonResponse(response, 200, result)
               , throwable -> Utils.fireSingleMessageResponse(response, 500, throwable.getMessage()));

各位可依葫蘆畫瓢將其改為自己的形式，其中的重點(diǎn)在于以“vertx.executeBlocking”方式來執(zhí)行Handler的代碼。

在稍微正規(guī)的隊(duì)伍中，自動化測試應(yīng)該已經(jīng)是一個標(biāo)準(zhǔn)實(shí)踐了，并且Vert.x對于測試也提供了支持。

不過，我不喜歡。原因有幾個：

Vert.x Unit是基于JUnit，而我已經(jīng)有鐘情的測試框架：Spock。相比起JUnit而言，后者簡直可以說是Java測試領(lǐng)域的戰(zhàn)斗機(jī)。

好的單元測試本來就是要盡量少的依賴所用框架，注意這一點(diǎn)之后，盡力將類設(shè)計(jì)得好測試，這樣的結(jié)果就是普通的單元測試類編寫。既然有讓人爽的工具用，也就沒有必要去用Vert.x Unit了。

對于集成測試，直接模擬實(shí)際的環(huán)境，再加上合適的timer，目前看來也還不錯。而且Vert.x Unit中也一樣需要用timer，這樣一來，也就沒有必要專門用它了。

為了證明我所言非虛，大家可以去看看dgate和dfx的測試代碼。這里給出兩個例子：

集成測試

單元測試

都是基于Spock寫的，各位可以體驗(yàn)其酸爽度。

在本系列第一篇里，我就提出了一個鐘意的工程結(jié)構(gòu)組成，但里面沒有提到“運(yùn)行時外部配置文件”這一常見的實(shí)踐。

經(jīng)過若干項(xiàng)目的錘煉之后，目前對于這種運(yùn)行時的外部配置文件，我基本形成了一個固定套路：Groovy DSL + Groovy ConfigSlurper。它倆簡直是完成這一任務(wù)的絕配，比起Vert.x的提供的json配置文件要爽太多。

看看Gradle的build文件，你就可以知道這種DSL的靈活度可以到什么程度，更何況Groovy的語法對于Java開發(fā)者極其友好。

或許有人會覺得Groovy不酷，甚至有點(diǎn)鄙夷，言必稱Scala、Clojure、Kotlin、Go或者Rust。對此，哥只想說：作為開發(fā)者，最讓人鄙夷的是交不出活，客戶才不關(guān)心你用什么語言呢！

dgate是我寫的一個基于vertx的輕量級網(wǎng)關(guān)，所有的配置全部通過配置文件來定義，無需數(shù)據(jù)庫。關(guān)于它的詳細(xì)介紹，可以參見其文檔。為了說明上一節(jié)采用Groovy DSL的靈活度，這里展示幾個dgate的配置例子。

利用dgate的mock功能，分離開的前后端開發(fā)人員可以并行工作，只需將mock響應(yīng)配置到dgate的配置文件中就好。

"/summary" {
    expected {
        statusCode = 200
        payload {
            eqLocations = []
            opRateInLast30Days = []
            myOrgs = [
                ["name": "org1", "admin": false]
            ]
        }
    }
}

動態(tài)Mock為那些返回動態(tài)結(jié)果（如某些情況下成功，某些情況下失?。┑腢RL模擬提供了便利。

"/login" {
    required = ["sub", "password"]
    methods = [HttpMethod.GET, HttpMethod.POST]
    expected {
        statusCode = 200
        payload = {
            JWTAuth jwtAuth = Utils.createAuthProvider(Vertx.vertx())
            JWTTokenGenerator tokenGenerator = new JWTTokenGenerator(jwtAuth)
            [token: tokenGenerator.token(["sub": "……", "name": "……", "role": "normal"], 200)]
        }
    }
}

上例將模擬一個實(shí)際的動態(tài)JWT，這樣的好處在于，方便前端/移動端開發(fā)直接去完成刷新token或重新登錄的過程，而不需要再針對此場景做其他特殊處理。

請注意，為了產(chǎn)生動態(tài)結(jié)果，此處的payload使用的是閉包，而不像前一例用的是Map。此時，閉包的返回值為Mock響應(yīng)的結(jié)果。

以上的例子已經(jīng)充分展現(xiàn)了將Groovy DSL作為運(yùn)行時外部配置的能力，可以說是完勝Vert.x自帶的json配置方式。

好啦，本期內(nèi)容就此結(jié)束，請保持關(guān)注，期待下期繼續(xù)！

Vert.x入坑須知（1）

Vert.x入坑須知（2）