怎樣編寫測(cè)試類測(cè)試分支

對(duì)此沒有太多疑問，測(cè)試代碼的方式是一個(gè)有爭(zhēng)議的問題。 不同的測(cè)試技術(shù)由于各種原因（包括企業(yè)文化，經(jīng)驗(yàn)和總體心理觀點(diǎn)）而受到不同開發(fā)人員的青睞。

例如，您可能更喜歡編寫經(jīng)典的單元測(cè)試，通過檢查返回值來單獨(dú)測(cè)試對(duì)象的行為。 您可能會(huì)喜歡經(jīng)典存根或偽造的物品； 或者您可能喜歡使用模擬對(duì)象模擬角色，甚至使用模擬對(duì)象作為存根。 這個(gè)博客以及我接下來的幾篇博客都采用了一種非常非常通用的設(shè)計(jì)模式，并研究了可以采用的不同測(cè)試方法。

我正在使用的設(shè)計(jì)模式顯示在下面的UML圖中，這是我以前使用過的，主要是因?yàn)樗侨绱似毡椤?您可能不喜歡它-它的設(shè)計(jì)更像是“問不說”而不是“告訴不問”，但是它適合這個(gè)簡單的演示。

在此示例中，上面的普遍模式將用于從數(shù)據(jù)庫中檢索和驗(yàn)證地址。 可以從我的GitHub存儲(chǔ)庫中獲得的示例代碼以一個(gè)簡單的Spring MVC Webapp為起點(diǎn)，并使用一個(gè)小型MySQL數(shù)據(jù)庫來存儲(chǔ)地址，其原因無非是我已經(jīng)在筆記本電腦上本地運(yùn)行了服務(wù)器。

就測(cè)試而言，博客將集中于測(cè)試服務(wù)層組件AddressService：

@Component public class AddressService {private static final Logger logger = LoggerFactory.getLogger(AddressService.class);private AddressDao addressDao;/*** Given an id, retrieve an address. Apply phony business rules.* * @param id* The id of the address object.*/public Address findAddress(int id) {logger.info("In Address Service with id: " + id);Address address = addressDao.findAddress(id);businessMethod(address);logger.info("Leaving Address Service with id: " + id);return address;}private void businessMethod(Address address) {logger.info("in business method");// Do some jiggery-pokery here....}@Autowiredvoid setAddressDao(AddressDao addressDao) {this.addressDao = addressDao;}}

…如上面的代碼所示，您可以看到非常簡單：它具有findAddress（...）方法，該方法將單個(gè)地址的ID（或表主鍵）作為輸入。 它調(diào)用數(shù)據(jù)訪問對(duì)象（DAO），并假裝在將Address對(duì)象返回給調(diào)用者之前進(jìn)行一些業(yè)務(wù)處理。

public class Address {private final int id;private final String street;private final String town;private final String country;private final String postCode;public Address(int id, String street, String town, String postCode, String country) {this.id = id;this.street = street;this.town = town;this.postCode = postCode;this.country = country;}public int getId() {return id;}public String getStreet() {return street;}public String getTown() {return town;}public String getCountry() {return country;}public String getPostCode() {return postCode;} }

如上所述，我將介紹測(cè)試此代碼的不同策略，其中一些我保證您會(huì)討厭。 第一個(gè)仍然被許多開發(fā)人員和組織廣泛使用的是……

不要寫任何測(cè)試

令人難以置信的是，某些人和組織仍在這樣做。 他們編寫代碼，將其部署到Web服務(wù)器并打開一個(gè)頁面。 如果頁面打開，則他們將發(fā)送代碼；如果頁面未打開，則他們將修復(fù)代碼，對(duì)其進(jìn)行編譯，然后重新部署，重新加載Web瀏覽器并重新測(cè)試。

我見過的關(guān)于該技術(shù)的最極端的例子：幾年前，在一個(gè)著名的政府項(xiàng)目中，更改代碼，部署到服務(wù)器，運(yùn)行代碼，發(fā)現(xiàn)錯(cuò)誤并再次循環(huán)。 我猜想，為了節(jié)省資金，分包商從“離岸”業(yè)務(wù)中引入了一批廉價(jià)且缺乏經(jīng)驗(yàn)的程序員，并且沒有足夠的經(jīng)驗(yàn)豐富的程序員來指導(dǎo)他們。 所討論的模塊是一個(gè)基于Spring的簡單消息驅(qū)動(dòng)Bean，它從一個(gè)隊(duì)列中獲取消息，應(yīng)用了一些業(yè)務(wù)邏輯，然后將其推入另一個(gè)隊(duì)列：簡單隊(duì)列。 最初的作者首先編寫了一些測(cè)試，然后將代碼傳遞給其他經(jīng)驗(yàn)不足的團(tuán)隊(duì)成員。 當(dāng)代碼更改并且測(cè)試失敗時(shí)，他們只是關(guān)閉了所有測(cè)試。 測(cè)試包括將MDB部署到EJB容器（Weblogic），將消息推送到系統(tǒng)的前端，觀察來自另一端的消息并調(diào)試整個(gè)過程中的日志。 您可能會(huì)說這樣的端到端測(cè)試還不錯(cuò)，但是部署MDB和運(yùn)行測(cè)試只花了一個(gè)小時(shí)：在一個(gè)工作日內(nèi)，這是8個(gè)代碼更改。 發(fā)展不完全Swift！

我的工作？ 修復(fù)過程和代碼。 解決方案？ 編寫測(cè)試，運(yùn)行測(cè)試并重構(gòu)代碼。 該模塊從零測(cè)試變成了大約40個(gè)單元測(cè)試和幾個(gè)集成測(cè)試，并且經(jīng)過改進(jìn)并最終交付。 做完了

大多數(shù)人會(huì)對(duì)這種技術(shù)有自己的看法，而我的看法是：它產(chǎn)生了不可靠的代碼； 使用此技術(shù)需要花費(fèi)更長的時(shí)間編寫和交付代碼，因?yàn)槟ㄙM(fèi)大量時(shí)間等待服務(wù)器啟動(dòng)，部署WAR / EJB等。并且，通常由經(jīng)驗(yàn)不足的程序員或那些沒有使用過此功能的程序員使用技術(shù)–您確實(shí)遭受了痛苦。 我可以說我從事的項(xiàng)目是編寫測(cè)試的項(xiàng)目，而其他開發(fā)人員則不在。 測(cè)試團(tuán)隊(duì)在我的代碼中發(fā)現(xiàn)的bug很少，而其他開發(fā)人員正在修復(fù)大量的bug，并瘋狂地努力按時(shí)完成任務(wù)。 我是一個(gè)出色的程序員，還是編寫測(cè)試能帶來收益？ 根據(jù)經(jīng)驗(yàn)，如果您使用此技術(shù)，則將有很多其他錯(cuò)誤要修復(fù)，因?yàn)槟鸁o法輕松且可重復(fù)地測(cè)試與您開發(fā)的故事相伴的多種場(chǎng)景。 這是因?yàn)樗ㄙM(fèi)的時(shí)間太長，您必須記住每種情況，然后手動(dòng)運(yùn)行它們。

我確實(shí)想知道，不寫測(cè)試技術(shù)是否是自1960年代以來的宿醉，當(dāng)時(shí)計(jì)算時(shí)間非常昂貴，您必須手動(dòng)在打Kong卡或紙帶上編寫程序，然后使用“真值表”進(jìn)行目視檢查。 當(dāng)您對(duì)自己的代碼工作感到滿意后，便將其發(fā)送到計(jì)算機(jī)室并運(yùn)行您的代碼-我還不算老，無法記住60年代的計(jì)算。 機(jī)器時(shí)間昂貴的事實(shí)意味著自動(dòng)化測(cè)試是不可能的。 盡管計(jì)算機(jī)的速度越來越快，但這種過時(shí)的范例仍在繼續(xù)，逐漸退化為一種錯(cuò)誤，您在其中錯(cuò)過了勤奮的精神檢查，只執(zhí)行了代碼，如果代碼破損，則您對(duì)其進(jìn)行了修復(fù)。 這種退化的范式仍在學(xué)校，學(xué)院和書籍中教授，直到近幾年才受到挑戰(zhàn)。

這就是為什么很難說服人們改變他們的習(xí)慣嗎？

這種技術(shù)的另一個(gè)主要問題是項(xiàng)目可能會(huì)陷入癱瘓狀態(tài)。 就像我在上面說的那樣，使用這種技術(shù)，您的錯(cuò)誤數(shù)將很高，并且給項(xiàng)目經(jīng)理帶來不好的印象，使他們認(rèn)為代碼會(huì)發(fā)臭并強(qiáng)制執(zhí)行以下想法：除非絕對(duì)必要，否則不要更改代碼，因?yàn)檫@可能會(huì)破壞某些東西。 經(jīng)理常常對(duì)授權(quán)代碼更改不滿意，他們通常對(duì)開發(fā)人員不信任，也不會(huì)對(duì)它們進(jìn)行微管理。 確實(shí)，開發(fā)人員自己對(duì)添加代碼更改非常猶豫，因?yàn)槠茐哪承﹥?nèi)容會(huì)使它們看起來很糟糕。 他們所做的更改盡可能的小，并且沒有任何重構(gòu)。 隨著時(shí)間的流逝，這會(huì)增加混亂，并且代碼的退化甚至?xí)兊酶蟆?

雖然我認(rèn)為您應(yīng)該加載并查看頁面以確保所有功能都正常運(yùn)行，但只有在有大量測(cè)試告訴您代碼可以正常工作時(shí)，才應(yīng)該在故事的結(jié)尾進(jìn)行操作。

我希望當(dāng)我總結(jié)這種方法很糟糕的時(shí)候（盡管時(shí)間會(huì)證明一切）時(shí)，我不會(huì)引起爭(zhēng)議。 您可能還想知道為什么要包含它，原因是要指出它很爛，并在下面的博客中提供了一些替代方法。

參考： 測(cè)試技術(shù)–第1部分–不通過Captain Debug博客從我們的JCG合作伙伴 Roger Hughes 編寫測(cè)試 。

相關(guān)文章 ：

• 端到端測(cè)試的濫用–測(cè)試技術(shù)2
• 您應(yīng)該對(duì)什么進(jìn)行單元測(cè)試？ –測(cè)試技術(shù)3
• 常規(guī)單元測(cè)試和存根–測(cè)??試技術(shù)4
• 使用模擬的單元測(cè)試–測(cè)試技術(shù)5
• 為舊版代碼創(chuàng)建存根-測(cè)試技術(shù)6
• 有關(guān)為舊版代碼創(chuàng)建存根的更多信息–測(cè)試技術(shù)7
• 為什么要編寫單元測(cè)試-測(cè)試技巧8
• 一些定義–測(cè)試技術(shù)9
• 使用FindBugs產(chǎn)生更少的錯(cuò)誤代碼
• 在云中開發(fā)和測(cè)試

翻譯自: https://www.javacodegeeks.com/2011/11/testing-techniques-not-writing-tests.html

怎樣編寫測(cè)試類測(cè)試分支

總結(jié)

以上是生活随笔為你收集整理的怎样编写测试类测试分支_测试技巧–不编写测试的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。