如何編寫測試、有哪些用于管理測試集合的最佳實(shí)踐這些主題并不新鮮。從 “在構(gòu)建過程中使用集成測試的正確方式” 到談?wù)摗霸趩卧獪y試中恰當(dāng)?shù)啬�擬環(huán)境”， 再到“ 代碼覆蓋率以及如何找到哪些是你真正需要測試的代碼”。

但是，今天我們想和你談?wù)撘幌盗行〗ㄗh，這些建議可以幫助你在頭腦中理清測試自下而上是如何運(yùn)作的。從如何構(gòu)造一個(gè)簡單的單元測試到對(duì) mock(模擬) 和 spy(監(jiān)視) 以及復(fù)制粘貼測試代碼更高層次的理解。

AAArrr，像海盜一樣說話?模式

和大部分軟件開發(fā)一樣，模式通常都是一個(gè)不錯(cuò)的開始。無論是想要通過工廠來創(chuàng)建對(duì)象，或者希望將web應(yīng)用程序中的關(guān)注點(diǎn)分散到Model、View和Controller中，在它們背后通常都會(huì)有一個(gè)模式，幫助你理解正在發(fā)生什么并解決困難。 那么，一個(gè)典型的測試看上去應(yīng)該是怎么樣的?

當(dāng)我們編寫測試時(shí)，其中一個(gè)最有用但卻極其簡單的模式是計(jì)劃-執(zhí)行-斷言(Arrange-Act-Assert)，簡稱AAA。

這個(gè)模式的前提是所有測試都應(yīng)該遵循默認(rèn)布局。測試系統(tǒng)所必需的全部條件和輸入都應(yīng)該在測試方法開始的時(shí)候被設(shè)置(Arrange)。在計(jì)劃好所有前置條件后，我們通過觸發(fā)一個(gè)方法或者檢查系統(tǒng)的某些狀態(tài)的方式，在測試系統(tǒng)上運(yùn)行(Act)。最后，我們需要斷言(Assert)測試系統(tǒng)是否已經(jīng)生成了期望的結(jié)果。

讓我們來看一個(gè)Java JUnit測試的示例，它展示了這種模式： @Test public void testAddition() { // Arrange Calculator calculator = new Calculator(); // Act int result = calculator.add(1, 2); // Assert assertEquals("Calculator.add returns invalid result", 3, result); }

看看代碼流多么精準(zhǔn)!計(jì)劃-執(zhí)行-斷言模式可以讓你快速理解測試的功能。偏離了這個(gè)模式后會(huì)很容易寫出非常糟糕的代碼。

牢記迪米特法則規(guī)則

迪米特法則在軟件上面應(yīng)用了最小知識(shí)原則，減小了單元的耦合——這一直是在開發(fā)軟件的設(shè)計(jì)目標(biāo)。

迪米特法則可以表述為一系列的規(guī)則：

在方法中，一個(gè)類的實(shí)例可以調(diào)用該類的其它方法;在方法中，實(shí)例可以查詢自己的數(shù)據(jù)，但不能查詢數(shù)據(jù)的數(shù)據(jù)，即實(shí)例的數(shù)據(jù)比較復(fù)雜時(shí)，不能進(jìn)行嵌套查詢;當(dāng)方法接收參數(shù)時(shí)，可以調(diào)用參數(shù)的第一級(jí)方法;當(dāng)方法創(chuàng)建了一些局部變量的實(shí)例后，這個(gè)類的實(shí)例可以調(diào)用這些局部變量的方法;不要調(diào)用全局對(duì)象的方法。

那么，就測試而言，這些意味著什么呢?好吧，由于迪米特法則減少了應(yīng)用程序各部分之間的耦合，這意味著測試應(yīng)用程序中的各個(gè)部分變得更加容易。為了要查看該法則如何為測試提供幫助，我們來看一個(gè)定義非常糟糕的類，它違背了迪米特法則：

考慮下面這個(gè)我們要測試的類： public class Foo() { public Bar doSomething(Baz aParameter) { Bar bar = null; if (aParameter.getValue().isValid()) { aParameter.getThing().increment(); bar = BarManager.getBar(new Thing()); } return bar; } }