Spock Primer 翻译
起因
最近要搞groovy介紹，準備做成一系列的東西，參考github上的計劃。
https://github.com/javahub/groovy_hello
spock沒有找到翻譯文檔，動手把最重要的一章primer翻譯下，想起了c++ primer。
就當作翻譯練習了。
目前項目大使用spock做測試，也是比較推薦的方式。簡潔清爽
Spock Primer
這一章假設你有關于groovy與單元測試基本知識。如果你是java開發者，但沒聽說過groovy，別擔心，groovy對java開發者來說非常友好。事實上，groovy相關抓喲設計目標是與java共存腳本語言。因此只需要繼續并查看groovy doc
這一章目標是教會你足夠寫真實spec的spock，并且激起你的食欲
學習更多關于groovy，點http://groovy-lang.org/.
學些更多關于單元測試，點 http://en.wikipedia.org/wiki/Unit_testing.
術語
讓我們開始一些定義：spock 讓你寫描述期望特性展示spec作為系統關注點，系統感興趣關注點可以是一個簡單的類和整個系統中的任何事，并且被稱為spec下的系統（sus）。一個特性描述開始于spec sus的臨時快照并且作為一個合作者。快照被稱作特性fixture
接下來的部分沿著在spock的spec可能組合構建blocks。一個常規spec能使用它們的中一部分。
Specification
一個spec表現為繼承spock.lang.Specification的一個groovy 類。spec名字通常描述系統或系統操作。例如： CustomerSpec, H264VideoPlayback, and ASpaceshipAttackedFromTwoSides是一個規范合理的名稱
spec類包含一系統有用的方法，此處它含義為spec用Sputnik在junit中運行，spock的junit runner，感謝Sputnik，spock spec能運行在大多數的ides和構建工具
Fields
def obj = new ClassUnderSpecification() def coll = new Collaborator()對象實例字段是一個好的地方去存儲屬于spec fixture 。它是一個好的實踐在正確初始化他們在定義時候。（語義上它等價于初始化他們在setup()方法）.存儲這些實例字段的對象不應該分享在feature方法之間。取而代之，每個特性方法得到他們自己的初始化對象。這個幫助在相互間獨立隔離特性方法，提供一個好的目標。
@Shared res = new VeryExpensiveResource()一些時候你需要分享一個對象在特性方法之間。例如對象可能創建很昂貴，或者你可能想在不同特性方法指南交互。為了實現這一點，定義@Shared 字段，它最好事初始化正確字段在一個定義點（語義上等價等價與setupSpec）
static final PI = 3.141592654靜態字段應該是常量，寧一方面shared字段是完美的，因為他的語義表現了更好的定義。
Fixture Methods
Fixture Methods def setup() {} // run before every feature method def cleanup() {} // run after every feature method def setupSpec() {} // run before the first feature method def cleanupSpec() {} // run after the last feature methodfixture方法負責在環境設置清理在每個特性方法運行。通常它是一個好的idea使用刷新fixture 方法在為每個fixture方法，在setup() and cleanup() 做這個。偶爾對特性方法分享是由意義的。他實現了分享使用shared字段與setupSpec() and cleanupSpec() methods。
所有fixture方法都是可選擇的。
說明：setupSpec cleanupSpec 方法不能飲用實例字段
Feature Methods
def "pushing an element on the stack"() { // blocks go here }Feature 方法是一個spec核心，他描述了你期待系統的在sus下的特性集。根據約定，特性方法唄命名字符串常量。試著為你的特性方法選擇一個好的方法。并且隨心使用你喜歡的特性。
概念，一個特性方法包括四個語義段：
設置特性的fixture
提供sus的刺激
描述系統期待的結果
清理fixture
Blocks
spock實現支持每個feature方法概念語法階段作為一個特性方法。對結束來說，特性方法被構建為一個叫做blocks。blocks開始于一個label并且擴展開始下一個label或者方法結束。這個有六個blocks：setup, when, then, expect, cleanup, and where blocks.。任何語句在方法開始與第一次
隱含的setup block之間。
一個特性方法必須至少一個清晰的label，實際上，一個直接的block表現。Blocks 決定一個方法不同部分并且不能嵌套。
Blocks2Phases
這個右側圖片展示block如何匹配一個特性方法語法概念。那里的block有一個特殊的角色，被簡單的展現出來，但首先讓我們有一個近距離查看這個block
Setup Blocks
setup: def stack = new Stack() def elem = "push me"這個setup block 你能做任何你想setpup工作為你想描述的特性。他可能不能被前面其他block處理，并且不能重復。一個setup block 沒有任何特殊的語義。setup: label時可選的并被提交。結果在一個直接設置的block。given: label是一個setup的別名，并且一些時候導致更多的刻的特性方法描述。
When and Then Blocks
when與then blocks when: //刺激 then://響應when與then blocks 一直一起出現。他們描述一個刺激發生并響應期待。
when blocks能包含任意代碼；
then blocks被禁止使用在條件，異常條件，交互與變量定義。
一個特性方法可能匹配多個when-then 塊
Conditions
Conditions被描述為一個期待的狀態，必須像junit的assertions。然而，conditions被寫做一個描述布爾表達式，消除為必需的assertion API（恰恰更多的是一個條件唄處理為一個非布爾表達式，將會被作為處理根據groovy truth）讓我們來看一些場景在以下
stack.size() == 2 | | | | 1 false盡可能保持在每個小特性方法里的條件數量。一到五個是一個好的指導。如果你有更多，你得問自己，如果在一個場景下有多個不相關的特性被提及。答案如果是yes，在幾個小的特性方法重構。如果你的場景時只有不同的值，考慮使用數據表驅動（spock帶有這個特性）
如果一個條件沒通過，spock提供什么樣的反饋。讓我們試并改變第二個場景
如你所見，spock在一個場景執行期間，捕獲所有值處理在，并在一個容易理解的形式表現他們。干得漂亮，不是么？
Implicit and explicit conditions
場景必須有一個 then blocks and expect blocks其中之一。出了調用空方法雨歸類表達式作為交互，所有頂級表達式在這些塊里面是隱含作為場景對待。在別的地方使用題哦安，你需要設計他們使用groovy的assert關鍵字。
def setup() { stack = new Stack() assert stack.empty }如果顯試條件被觸發，他將處理一些相同的診斷信息作為隱含條件。
Exception Conditions
異常場景唄使用描述作為一個when 語句塊應該拋出一個異常。他們被定義使用 thrown()方法，被傳遞期待的異常類型。例如，描述被彈出一個空stack 應該拋出EmptyStackException，你能像下面這樣寫
when: stack.pop()then: thrown(EmptyStackException) stack.empty如你所見，異常場景可能是跟別的場景相關。這個特別有用為對詳細說明期待內容作為異常，訪問這個異常，首先綁定一個變量。
when: stack.pop()then: def e = thrown(EmptyStackException) e.cause == null寧外，你也可以使用上面語法作為一個輕微有變化
when: stack.pop()then: EmptyStackException e = thrown() e.cause == null這個語法有兩個小優勢，首先，異常變量時強類型，讓它非常容易被ide補全。其次，場景讀起來有一點更像句子。注意，如果沒有異常類型被傳遞在thrown方法，它從左邊的變量類型被推斷
一些時候我們需要表達一個異常不應該被拋出。例如，讓我們嘗試表達hashmap不應該接受null key。
def "HashMap accepts null key"() {setup:def map = new HashMap()map.put(null, "elem") }一些時候我們需要表達一個異常不應該被拋出。例如，讓我們嘗試表達hashmap不應該接受null key。
這個表示不能揭示代碼的含義。 是否有人離開構建之前就完成實現了這個方法。畢竟，場景在哪里？ 幸運是我們能做更好。
def "HashMap accepts null key"() {setup: def map = new HashMap()when:map.put(null, "elem")then:notThrown(NullPointerException) }通過使用notThrown。我們能使清晰在一個特殊的NullPointerException 不應該被拋出。（按照Map.put()方法的約定，它是正確的事情不支持null keys在map上使用。）然而，方法將會失敗如果有任何逼的異常拋出。
Interactions
盡管條件描述了一個對象的狀態，交互描述了對象互相間關系。交互被轉用于一章。所以我們只快速給一個例子在這。假設我們想描述從一個發布者到訂閱者的事件流。代碼如下
def "events are published to all subscribers"() {def subscriber1 = Mock(Subscriber)def subscriber2 = Mock(Subscriber)def publisher = new Publisher()publisher.add(subscriber1)publisher.add(subscriber2)when: publisher.fire("event")then: 1 * subscriber1.receive("event") 1 * subscriber2.receive("event")Expect Blocks
一個expect block 比then block有更多的限制。他可能包含場景與變量定義。它是有用的情形當他更加自然描述刺激與期待結果響應在一個簡單的表達式里。例如，比較下面兩個描述 Math.max()方法。
when:def x = Math.max(1, 2)then:x == 2expect:Math.max(1, 2) == 2盡管兩個片段時語義等價。第二個是更清晰選擇。作為一個指引，使用when-then 去描述帶有副作用。并且期待描述純碎的函數方法。
TIP
利用groovy jdk方法像any（） every（）去創建更多表現力與簡潔的條件。
Cleanup Blocks
setup: def file = new File("/some/path") file.createNewFile() // ... cleanup: file.delete()cleanup block
只能跟著where block后面。并且不能重復。像一個cleanup 方法，它作為釋放資源使用作為一個特性方法使用，運行即使特性方法拋出異常。因此，cleanup block 必須防御編程。在最糟糕的情況下，它必須優雅的處理在特性方法里拋出異常的第一個語句。并且所有本地變量有默認值。
TIPS
groovy的安全引用操作精簡寫防御是代碼
對象級別的spec 通常不用cleanup方法。作為唯一資源他們消費內存，自動被回收通過垃圾收集齊。更多粗力度spec，但是，可能使用clean 塊 清理文件系統關閉數據庫連接，關閉網絡服務
}
This where block effectively creates two "versions" of the feature method: One where a is 5, b is 1, and c is 5, and another one where a is 3, b is 9, and c is 9.
這個where 塊創建兩個版本特性方法非常有效：One where a is 5, b is 1, and c is 5, and another one where a is 3, b is 9, and c is 9.
where block 將會在數據驅動測試章節解釋
Helper Methods
一些時候特性方法增長巨大在 and/or包含重復代碼。在這種情形下引入一個多個幫助方法會有意義。兩個好的候選者為幫助方法是setup/cleanup 邏輯與復雜場景。分解出前者是直接的，讓我們看下場景
def "offered PC matches preferred configuration"() { when: def pc = shop.buyPc()then: pc.vendor == "Sunny" pc.clockRate >= 2333 pc.ram >= 4096 pc.os == "Linux"}
如果碰巧你也是電腦極客，你更愿意pc配置是詳細的，或者你可能想比較供應從同的商店。因此，讓我們分解條件
}
def matchesPreferredConfiguration(pc) { pc.vendor == "Sunny" && pc.clockRate >= 2333 && pc.ram >= 4096 && pc.os == "Linux"}
新的幫助方法matchesPreferredConfiguration 由簡單的布爾表達式組成作為結果返回。
這是好的除了那些一個不充分的供應被描述。
不是很有什么幫助。幸運的事，我們可以做更好
當在一個幫助方法分解場景時，必須思考兩個點：首先，隱含條件必須轉換為顯性條件使用assert關鍵字。其次，幫助方法必須返回空類型。否則，spock會解釋返回值為失敗條件，這并不是我們想要的。
作為猜想，改進的幫助方法告訴我們確切什么是錯的。
Condition not satisfied:assert pc.clockRate >= 2333| | || 1666 false...條件不是滿意：
最后一個建議：盡管重用代碼是一個好事情，但不要是他太遠。更聰明使用fixture 和幫助方法能增加耦合在特性方法間。如果你重用太多或者有錯誤代碼，你將以脆弱和艱難改進的spec結束。
Specifications as Documentation
寫得好的spec作為一個源碼信息價值點。尤其是對高級別spec目標是更廣泛的受眾不知是開發者（架構師 領域專家 客戶等）它是有道理的提供更多信息使用自然語言比只是使用規格與特性的名稱。因此，spock提供了一種方式附屬文本話的描述使用塊。
setup: "open a database connection"// code goes hereIndividual parts of a block can be described with and::setup: "open a database connection"// code goes hereand: "seed the customer table"// code goes hereand: "seed the product table"一個and 標簽 跟著描述能插入到特性方法的任何位置，沒有改變方法語義。
在行為驅動測試，面向客戶的特性被描述在一個given-when-then 格式。spock直接支持這個風格的spec使用given標簽
given: "an empty bank account"// ...when: "the account is credited $10"// ...then: "the account's balance is $10"// ...As noted before, given: is just an alias for setup:.作為之前的提示，given知識setup的一個別名
塊描述不應該出現在源碼里。但應該在運行時可用對spock運行時。塊描述用法的計劃被增強診斷信息并且文本化的報告被所有利益相關者同樣理解。
擴展
如所見，spock提供許多寫spec功能。然而總是有這種時候，當一些別的東西被需要。因此，spock提供了一個基于攔截的擴展機制。擴展通過注解被直接激活。當前，spock附帶一下指令
期待一個特性方法去完成打斷。@FailsWith有兩個用例：首先，文檔化我們知道的bug不需要立刻解釋。其次，替換異常條件在一個確定的角落用例在后面不能使用。在所有的用例，異常條件不是優選。
學習怎樣實現你自己的指令與擴展，去看擴展章節
Comparison to JUnit
盡管spock使用不同的技術，大部分概念和特性唄激活從junit。這有一個粗的比較
comparison
|Spock|JUnit|
|--|--|
|Specification|Test class|
|setup()|@Before|
|cleanup()|@After|
|setupSpec()|@BeforeClass|
|cleanupSpec()|@AfterClass|
|Feature|Test|
|Feature method|Test method|
|Data-driven feature|Theory|
|Condition|Assertion|
|Exception condition|@Test(expected=…?)|
|Interaction|Mock expectation (e.g. in Mockito)|
總結
以上是生活随笔為你收集整理的Spock Primer 翻译的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： nginx的502错误及常见解决方法汇总
- 下一篇： GridView数据导入Excel/Ex